jjkola
commented
1 month ago If we followed my suggestion then the next release would be v1.1.0. The backup and restore functionality does have change which could be said to be backwards incompatible but given the previous version did not work either, and if somebody were to use newer backup with older version of chroot-distro it would still work better as it would not be masked by system mounts.
Also, because there will never be a release with version v1.0.1 (given the problems with v1.0.0) there is no immediate need for separate release branch (although it would be nice from process point of view, i.e. consistent process, and also it will bring possible problems with branching forth thus making them actionable).
There is also the issue with automatic updates (having the updateJson property) but I think we should create a separate issue for that. If we could have that in the next release would be nice but it is not necessary. Maybe we could implement in the release after this (v1.2.0) to keep amount of changes manageable and to not unnecessarily lengthen the release process.
YasserNull
I'm thinking, that now that we have a development version which seems to fix several problems, that maybe we should make a new release. There is currently only main branch and one tag with name 'module'. The first version has been dubbed as v1.0.0.
Moving forward, I think we should define release process. First we should define the versioning scheme. For versioning there is basically two choices:
Calendar versioning takes the date of release and is formatted in specific way, for example 20240718, or 24.07. If versioning is done this way then there is significance added to version identifiers other than being unique. This is simple but may not convey the range of changes thus requiring the user to peruse change logs to determine if they can/want to update the version.
Semantic versioning on the other hand uses version format of major.minor.patch with a quite a few variations on format, most notably having -rc scheme (rc = release candidate), or some other development phase indicator. The interpretation of major and minor may vary depending on the organisation (major version change may mean that there was backward incompatible changes or it may mean that there was major user visible change, or combination of both). Minor versions may not be sequential as developers may decide to skip minor versions to denote big changes which will not warrant major version change.
My opinion is to use semantic versioning with major version change meaning there was backward incompatible change. Minor version would be denoting that there was a new feature, or some other significant change but which does not break backward compatibility. Patch version would be used for small bug fix only releases (or really small other changes, note: no breaking changes). If any of the numbers change then following numbers reset to zero. And for simplicity there is no need for rc stuff, and instead just increment the version as needed. If the version is not what we want it is easy to discard the version, and just create a new one.
After deciding version scheme we should define how we handle different versions in version control. If we use calendar versioning there is no need for complicated process, just tag each published version with correct version label. On the other hand, for semantic versioning there is more choices.
Available choices:
Personally I would use the second one with combined major.minor formatted release branch but given the state of the project the first one is okay too (it is easy to change to second one).
There is actually at least one more branching choice where the release branch is separated to major and minor branches and it makes it possible to develop multiple incompatible versions but given our situation this does not add anything compared to second choices.
Also, even if calendar versioning is used then it is possible to use separate release branches or even separate development branch.