Versioning improvements

[neobooru]

This post will mostly consist of ramblings about versioning and stuff. I am not really happy with how we currently do it, but I also don't have a clear solution. It's not really structured, but it's been bugging me for months now and I figured it's better to get something out there.

My main issue is that it is very 'dangerous' to merge any big changes into this repo. There are a few reasons for this.

First off, in the installation guide we recommend the usage of the latest tag for the images. Usually you want the latest tag to be stable, but in this project it's more like a beta tag. We also don't release versions often enough to have an easy rollback. For example, we are currently on version 2.5, but the previous version (2.4) is from 2020.
This means that there is no easy rollback in case a bug slips into the latest tag.

We also don't have do any front-end tests or end-to-end tests, which means that many things have to be manually tested.

Possible solution: Introduce a beta tag and change the latest tag to be stable
We could have a beta tag which has the latest changes from master. The latest tag would then NOT include the latest changes. We can also introduce a stable tag which is synonymous with latest.

I have also been thinking about adopting something like calendar versioning (like Home Assistant) as our current version numbers don't really mean anything and we are probably never going to leave major version 2. The downside with this however would be that version numbers lose their meaning altogether. With SemVer we can introduce 'major' features (e.g. mass-tag on upload) in minor versions (2.x versions), which in turn makes it easier to see the 'impact' of a version increment. With calendar version there is no way to tell how significant a change between two number is (without looking at the changelog). However, I do feel like calendar versioning is easier to work with in combination with a beta and stable tag/channel.

This all isn't very structured or well though out, but I figured it's better to put something out there than nothing at all. Please do share any thoughts or feelings you have about this.

[skybldev]

I agree with your proposed solution. You raised a good point in how latest is more like beta. I think that calendar versioning would be easier to work with too, but only in conjunction with SemVer by replacing the patch number with the date in DDMMYY form. This isn't proper SemVer but IMO it strikes that balance.

But these are only my opinions; I don't really have any experience with versioning and stuff :P

[noirscape]

Personally I would recommend going halfway with SemVer. I genuinely don't like calendar versioning - it's mostly useful for software you want/need to have continuously updated. Works well for a browser or an OS, not for a slower moving project like szuru. It'll make version numbers completely meaningless, something which isn't useful for anyone.

My personally recommended scheme is to take SemVer but apply it with an "update attention/user flow changes needed" mentality - if it's a new feature that doesn't require user attention during an update, do a minor or a patch bump (difference here is semantics - patch is for bugfixes, minor is for new features). If it requires user attention during an upgrade (ie. we probably should move the postgres version up to a more recent LTS - Postgres 9 is very much not supported anymore), then we do a major version bump.

Alternatively if the feature is so large that it makes using szuru feel completely new (no outstanding PRs for that rn - but I would have considered pools to fit this purpose), we can also do a major version bump. This is, at least in my experience, how most conventional user-facing software operates.