I didn't realize this pattern in the version numbers of BiT and it's fine. One thing to add: How explicit is this for others? If I see a version number with a postfix "dev" I know this is potentially a daily snapshot, if I see an odd version number I cannot infer this without background knowledge. Shall I open a PR or do you want to increment the version numbers directly? On Sun, 2022-10-23 at 17:16 +0200, Michael Büker wrote:
You're right, we should do that. Historically, odd revision numbers were exclusively used for unreleased development versions. That's why (for example) release version 0.9.24 was followed by 0.9.26, and 1.1.0 was followed by 1.1.2. In between those versions, 0.9.25 and 1.1.1 were used during development.
This tradition was broken only recently by the release of versions 1.2.1 in 2019 and 1.3.1 in 2021 -- both of which were desperate hotfixes, by the looks of it.
I think it would be appropriate to return to this historic scheme, which would mean: - our current working branch is designated 1.3.3 - our next release will be 1.3.4
Cheers, Michael
On Sun, Oct 23, 2022 at 05:01:33PM +0200, BiT dev wrote:
Our VERSION file at Github currently indicates "1.3.2" https://github.com/bit-team/backintime/blob/master/VERSION but it differs from the code of git tag "v1.3.2" due to our further development.
Also the dev version has still a hard-coded "version 1.3.2": https://github.com/bit-team/backintime/blob/4b09eba80237d64b84a3ed2c4aba1c44...
In the CHANGES file we already call the HEAD of master "Upcoming Release" (without any version number).
============================================================================================= How about updating the version number in VERSION file and config.py now to "1.3.3_dev" or similar to make it easier for us to recognize if a reported issue is related to the released 1.3.2 or a dev version from Github? =============================================================================================
This makes at least supporting Arch Linux easier since their packages are quite often directly pulled from Git (using a tag, commit ID or nothing) and I need to know the source code base for debugging...
Possible process for the future:
For a final release - both version number locations must be updated again, the release created - and then immediately a new dev version number set (potentially on a new branch than master).
_______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: foss@michael-bueker.de
Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: python@altfeld-im.de