Oops: Release v1.3.3 shows "1.3.3-dev" with "backintime --version"
I think our released version 1.3.3 does still show the "dev" postfix when asking for the version number via "backintime --version": https://github.com/bit-team/backintime/blob/8495f9dc3953343a0352bb3ffbdcfab7... I think we currently have no automated release process that fixes (or at least validates) the version number in the config.py file, haven't we?
Am 02.02.2023 17:44 schrieb BiT dev:
I think our released version 1.3.3 does still show the "dev" postfix when asking for the version number via "backintime --version":
https://github.com/bit-team/backintime/blob/8495f9dc3953343a0352bb3ffbdcfab7...
Moin. I don't think so. "main" says "1.3.3" https://github.com/bit-team/backintime/blob/e22c7f253fa048fab9119f4cbea34c0f... or https://github.com/bit-team/backintime/blob/main/common/config.py "dev" says "1.3.4dev" https://github.com/bit-team/backintime/blob/84d0f7d81c8a707d67d1adcdf3b8cb65... or https://github.com/bit-team/backintime/blob/dev/common/config.py Not sure how to find out to which branch a specific commit belongs. I would this was the "commit" where it changed: <https://github.com/bit-team/backintime/commit/5149b0e3e6f0975fa8312e370bc4a4...>
On Fri, 2023-02-03 at 08:28 +0000, c.buhtz@posteo.jp wrote:
Am 02.02.2023 17:44 schrieb BiT dev:
I think our released version 1.3.3 does still show the "dev" postfix when asking for the version number via "backintime --version":
https://github.com/bit-team/backintime/blob/8495f9dc3953343a0352bb3ffbdcfab7...
Moin. I don't think so.
"main" says "1.3.3" https://github.com/bit-team/backintime/blob/e22c7f253fa048fab9119f4cbea34c0f... or https://github.com/bit-team/backintime/blob/main/common/config.py
I have discovered the "v1.3.3-dev" release in wild while hunting an Arch Linux error.. It's no big deal at all and the only reason I am mentioning this here because we will get new issues for 1.3.3-dev which *may* be in fact the release version 1.3.3. The reason for this is visible in the commit tree (see screen shot): - The Git tag v1.3.3 was added first (and the config file still contains "1.3.3-dev") - The release commit incl. the config file change to "1.3.3" was done AFTER that The github "release" (which is NO Git but a Github concept!) is referencing the Git tag v1.3.3 (not "main"!). To prove this I have downloaded the zipped source code from the "Github release page" and checked the config.py file: https://github.com/bit-team/backintime/releases That is why all distro packages will publish the BiT release as v1.3.3-dev now ;-) Again: No big deal, we just have to be aware of this in case of issues... I think for future releases we have to prepare everything (incl. version numbers) first in "main" (or a relase candidate branch that is merged into "main" finally) and add the release Git tag AT THE END. Optionally we could patch this and inform the package maintainers (we mostly don't know I guess).
Dear Jürgen, thanks for breaking this down. I would put my angry finger on the GitHub folks. ;) I created a "Release" in "Draft" state first. I assume that GitHub did not updated the attached source tarballs when I changed the state from "Draft" to a real release. Damn! I'll put this on my release-checklist for the next time. Maybe we shouldn't over any source tarballs in such releases? Isn't a git tag enough? IMHO a source tarball is "doppelt gemoppelt" (translate this! *FG*). :D But it seems that the distros do use such a tarball. Debian itself used it and has a "1.3.3dev" in it. I'll open a bug report on Debian about that.
It's no big deal at all and the only reason I am mentioning this here because we will get new issues for 1.3.3-dev which *may* be in fact the release version 1.3.3.
OK, I'll keep this in mind.
I think for future releases we have to prepare everything (incl. version numbers) first in "main" (or a relase candidate branch that is merged into "main" finally) and add the release Git tag AT THE END.
That was my plan in the first place. :D But I was in a rush because of the Debian Freeze and should have slept more nights over this. And the GitHub Release feature was new to me.
Optionally we could patch this and inform the package maintainers (we mostly don't know I guess).
I wouldn't touch this and just keep it as it is and see whats coming up next. Thanks for figuring out. Kind Christian
participants (2)
-
BiT dev -
c.buhtz＠posteo.jp