Breaking changes freeze period suggestion

[sprrw]

The suggestion is to set up a transparent time period during which there will be no breaking changes (in relation to storage and database) to allow people to gracefully migrate to grimmory. This means database engine/schema, filesystem organization and so on, anything that would prevent a smooth drop-in transition. The conclusion of such term may also depend on reappearance of grimmory in certain popular charts, such as TrueNAS apps.

[alphafalcon]

I like the idea of making the transition as painless as possible.
I'm not sure a freeze is needed since currently migration is seamlessly possible and future grimmory versions need to be able to migrate from the current state. So to a hypothetical version 4.0 it shouldn't matter if it's migrating from booklore 2.2.1 or grimmory 2.3.0.

[obviouslyallie]

I think this post started before the first release but that is the current plan. 2.2.2 was a version that BL with an updated readme. 2.3 is the version without telemetry or aggressive donate buttons. The next few releases are mostly focused on outstanding bug fixes and framework fixes.

[imajes]

We're working hard on making releases as painless as possible but also allowing for changes to be effectively made. For now, we'll hold off on having true freeze periods -- for example, we have to be able to change some of the names in the build and that wouldn't have been possible during a freeze. Thank you for the idea though!