Why I did not choose Cwicly for my next big project…

No offense taken! :relieved:

You more or less repeated the case against separating concerns, and I truly understand your POV.

I was really hoping to get some insights from you on how to deal with breaking changes.

@oppi I’m not sure I have any insights to share other than the usual suspects:

  1. Always check the changelog
  2. Backup
  3. Test on a staging environment before updating on production

As for improving reliability (which is necessary, no doubt about it), all I can say is that I understand why some things are being handled before others, and I believe that the Cwicly team knows what they are doing (they have proven themselves over and over).

Maybe a public beta would help prevent releasing some bugs, but it really depends on engagement. Usually it helps just a little, and on some rare occasions it does help find some bugs that are difficult to test and may only appear on live websites in specific cases. Unfortunately, most of the time crucial feedback is really not there, and you end up having to test on your own (in this case the Cwicly team), which is something they already do.

I for example would love to beta-test, but I simply don’t have time to do that. Usually what happens is that people focus on everything else (including requesting features not in scope) but the critical points, and the problem is only identified after the GA is released.