release maintenance #32

So, I've been thinking about a few things lately, and figured the best way was to open an issue to put them on the table.

• How are we going to maintain releases ?
• For how long do we maintain releases ?
• Do we plan LTS releases and standard stable releases ?

My idea was to create a git branch for each release, so that we can then easily backport things to them in the long run, for however long we decide to maintain a given release. We could then tag individual commits in the branch, to make releases out of e.g: 2020-09-22 would be the original release, and if a bugfix needs to be produced later on it could be 2020-09-22.1, .2, .3, etc.

I don't have any opinion on LTS or how long to maintain a release, so any input is welcome.

Thoughts ?

It's a big ask for a two developer band to do LTS releases, maybe even 'stable' releases since it means we have to track multiple development trees. I think the best approach might be weekly or monthly builds with no point releases. When bugs hit, the user can just roll back the update and send us a report for us to debug.

I talked with you about this and it seems we've kind of agreed to release new builds regularly without any development branches. We'd then make it so users can pin versions, downgrade, etc. This requires making the data partition okay with downgrades to older versions.