Increase BiT version number now to indicate DEV status?

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).

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:

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:

On 23.10.2022 18:10, BiT dev wrote:
You're right, an additional suffix like "dev" is probably useful. If someone said "I'm running 1.3.3", then WE would know that it's a dev version, but the USER might not.
Shall I open a PR or do you want to increment the version numbers directly?
If you would take a moment to find all the right places to change the version number, that would be great. It's one of those things where it's most annoying to miss something ;) Cheers, Michael

Moin Folks, Am 23.10.2022 17:16 schrieb Michael Büker:
I disagree here and wouldn't recommend that. That "historic scheme" is historic. ;) I don't know a software that use that scheme today. I strongly recommend to use the standard known as "Semantic Versioning" (https://semver.org). You may know most of its component from "modern" software and most of it isn't new for you. About the "dev" status. In the current situation of our project I would say we use "1.3.3dev". But this is just a workaround. In a good "branching model" the "current development" status is represent by the "develop" branch. And that branch never carry a version number. Only the master/main branch will have a version number (or in some special situations a "release" branch). Nearly each commit in master/main is a release. But I would say we can discuss a "branching model" after we know how Germar will handle the GitHub rights for others to his repo. Let's keep it simple at the current point.
They don't use "nothing". They use tag or the commit-hash of the tagged commit. So I see no problem here. Just using the last master/main commit would be irresponsible for a distro maintainer.

Yes, Christian also makes some good arguments. You might be right – semantic versioning has been roughly followed since 1.2.0 (even though I think the jump to 1.3 was not justified). Anyway, continuing with 1.3.3 as the next release is also good, and you're right about the branching. Cheers, Michael On 23.10.2022 20:36, c.buhtz@posteo.jp wrote:

On Sun, 2022-10-23 at 18:36 +0000, c.buhtz@posteo.jp wrote:
They don't use "nothing". They use tag or the commit-hash of the tagged commit. So I see no problem here. Just using the last master/main commit would be irresponsible for a distro maintainer.
It depends on the purpose and 1 out of 4 BiT packages on AUR for Arch just pulls the HEAD (if I understand PKGBUILD correctly, see https://wiki.archlinux.org/title/PKGBUILD): https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=backintime-git This version caused the installation problems on Arch in #1333 and I start to love ARCH for this because it is a "canary bird" (early indicator of problems before BiT hits the mainstream distros)
I strongly recommend to use the standard known as "Semantic Versioning" (https://semver.org).
I personally never liked the semantic versioning since it doesn't tell me anything about how old the version is. I prefer the timestamped versioning via "yyyy.mm.dd-xxxx" which is also sortable to recognize newer versions due to the reversed date. It is e. g. partially used by Ubuntu ("22.04")... But this is just a matter of taste. I can live with any versioning systematics that is applied consequently.

Hello Jürgen Am 23.10.2022 23:20 schrieb BiT dev:
It depends on the purpose and 1 out of 4 BiT packages on AUR for Arch just pulls the HEAD
Why there are 4 BIT packages on one distro? I don't get it. And is AUR the official Arch distro or "just" the community repo of that distro?
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=backintime-git
I'm not sure about all details. But it seems to me that this script does builid an arch package with version "1.3.1.r1.ge1ae23dd" in it's name but use the current upstream master for that. This is a bug on Arch side.
This version caused the installation problems on Arch in #1333
When I see it right. This is definitely an Arch problem; a distro bug not related to upstream. In cases like this our upstream issues should be closed and redirected to the distro. It seems to me that the distro maintainer did something wrong in that build script. It is not our responsibility.

On Sun, 2022-10-23 at 21:32 +0000, c.buhtz@posteo.jp wrote:
$ yay -Ss backintime aur/backintime-git 1.3.1.r1.ge1ae23dd-2 (+27 0.01) Simple backup/snapshot system inspired by Flyback and TimeVault. Qt5 GUI version. aur/backintime-cli-git 1.3.1.r1.ge1ae23dd-2 (+27 0.01) Simple backup/snapshot system inspired by Flyback and TimeVault. CLI version. aur/ba ckintime-cli 1.3.2-2 (+287 1.81) Simple backup system inspired from the Flyback Project and TimeVault. CLI version. aur/backintime 1.3.2-2 (+287 1.81) Simple backup system inspired from the Flyback Project and TimeVault. QT5 GUI version. Like in every distro there are always many more or less "official" repos to install packages and AUR seems to be the main "community" repo for additional software: https://wiki.archlinux.org/title/Official_repositories
This irritated me too. The version in the display name is not used to pull from Git, this in determined by the "source" entry in PKGBUILD and this does not use a version or tag here, only the $_pkgname and $url vars to build the URL to the source code: _pkgname=backintime pkgname=($_pkgname-git $_pkgname-cli-git) pkgver=1.3.1.r1.ge1ae23dd pkgrel=2 url="https://github.com/bit-team/backintime" ... source=($_pkgname::git+$url.git) "man PKGBUILD 5" tells more about the source URL in the section "USING VCS SOURCES"...
It seems to me that the distro maintainer did something wrong in that build script. It is not our responsibility.
From a formal point of view this may be correct, as developer I am happy to get early feed-back as soon as possible to fix bugs timely.

Moin Jürgen, sorry I'm a bit stubborn, narrow-minded and learn-resistant here. ;) Am 23.10.2022 23:51 schrieb BiT dev:
Ah, two versions not four. Just the usual qt/cli separation in two versions. I know that Arch is rolling and doesn't have a major version number. But maybe the 27 and 28 indicates something like the "current stable" and "the previous/old stable"?
This irritated me too. The version in the display name is not used to pull from Git,
We should open a bug report about that at Arch to investigate this further and to get feedback from the distro maintainers. There must be (good) reasons why the do it that way and we should learn that. But IMHO distros shouldn't do that. No matter that there users now offers us with upstream bug reports because they involuntarily and unknowingly do test the latest upstream code in there distros.
as developer I am happy to get early feed-back as soon as possible to fix bugs timely.
I agree and see your point. From my point of view I see two bugs mixed here. At one side the distro specific Arch/AUR package is buggy. That is not our business except for just opening a ticket about that. Can you open a ticket against that AUR package and link it in #1333 please? But because of that bug we luckily received another bug report that indicates problems with our upstream-master code. Every time I read something about "distro" (e.g. the tag "distro-specific") in our Issues I'm confused. In that case I assume that is not for upstream and should thrown back to the distro maintainer and the ticket system there. Maybe this is a good Issue to learn for me why "distro-specific" tag is useful for us. Why? ;) Kind Christian

On 24.10.2022 10:34, c.buhtz@posteo.jp wrote:
Well, different distros have different defaults and conventions. It could be that some problem exists only on Wayland, but not X11. In that case, if a report mentions a Wayland-default distro, we have a hint. Also, there are different conventions about install paths, config locations, there could be different Qt versions etc. And rolling-release distros like Arch and OpenSUSE Tumbleweed are more likely to have the latest versions of python, rsync, Qt etc. So the goal is not to deal with the distro-packaging etc., but to identify failure conditions more easily based on the properties of the affected distros. Cheers, Michael

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:

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:

On 23.10.2022 18:10, BiT dev wrote:
You're right, an additional suffix like "dev" is probably useful. If someone said "I'm running 1.3.3", then WE would know that it's a dev version, but the USER might not.
Shall I open a PR or do you want to increment the version numbers directly?
If you would take a moment to find all the right places to change the version number, that would be great. It's one of those things where it's most annoying to miss something ;) Cheers, Michael

Moin Folks, Am 23.10.2022 17:16 schrieb Michael Büker:
I disagree here and wouldn't recommend that. That "historic scheme" is historic. ;) I don't know a software that use that scheme today. I strongly recommend to use the standard known as "Semantic Versioning" (https://semver.org). You may know most of its component from "modern" software and most of it isn't new for you. About the "dev" status. In the current situation of our project I would say we use "1.3.3dev". But this is just a workaround. In a good "branching model" the "current development" status is represent by the "develop" branch. And that branch never carry a version number. Only the master/main branch will have a version number (or in some special situations a "release" branch). Nearly each commit in master/main is a release. But I would say we can discuss a "branching model" after we know how Germar will handle the GitHub rights for others to his repo. Let's keep it simple at the current point.
They don't use "nothing". They use tag or the commit-hash of the tagged commit. So I see no problem here. Just using the last master/main commit would be irresponsible for a distro maintainer.

Yes, Christian also makes some good arguments. You might be right – semantic versioning has been roughly followed since 1.2.0 (even though I think the jump to 1.3 was not justified). Anyway, continuing with 1.3.3 as the next release is also good, and you're right about the branching. Cheers, Michael On 23.10.2022 20:36, c.buhtz@posteo.jp wrote:

On Sun, 2022-10-23 at 18:36 +0000, c.buhtz@posteo.jp wrote:
They don't use "nothing". They use tag or the commit-hash of the tagged commit. So I see no problem here. Just using the last master/main commit would be irresponsible for a distro maintainer.
It depends on the purpose and 1 out of 4 BiT packages on AUR for Arch just pulls the HEAD (if I understand PKGBUILD correctly, see https://wiki.archlinux.org/title/PKGBUILD): https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=backintime-git This version caused the installation problems on Arch in #1333 and I start to love ARCH for this because it is a "canary bird" (early indicator of problems before BiT hits the mainstream distros)
I strongly recommend to use the standard known as "Semantic Versioning" (https://semver.org).
I personally never liked the semantic versioning since it doesn't tell me anything about how old the version is. I prefer the timestamped versioning via "yyyy.mm.dd-xxxx" which is also sortable to recognize newer versions due to the reversed date. It is e. g. partially used by Ubuntu ("22.04")... But this is just a matter of taste. I can live with any versioning systematics that is applied consequently.

Hello Jürgen Am 23.10.2022 23:20 schrieb BiT dev:
It depends on the purpose and 1 out of 4 BiT packages on AUR for Arch just pulls the HEAD
Why there are 4 BIT packages on one distro? I don't get it. And is AUR the official Arch distro or "just" the community repo of that distro?
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=backintime-git
I'm not sure about all details. But it seems to me that this script does builid an arch package with version "1.3.1.r1.ge1ae23dd" in it's name but use the current upstream master for that. This is a bug on Arch side.
This version caused the installation problems on Arch in #1333
When I see it right. This is definitely an Arch problem; a distro bug not related to upstream. In cases like this our upstream issues should be closed and redirected to the distro. It seems to me that the distro maintainer did something wrong in that build script. It is not our responsibility.

On Sun, 2022-10-23 at 21:32 +0000, c.buhtz@posteo.jp wrote:
$ yay -Ss backintime aur/backintime-git 1.3.1.r1.ge1ae23dd-2 (+27 0.01) Simple backup/snapshot system inspired by Flyback and TimeVault. Qt5 GUI version. aur/backintime-cli-git 1.3.1.r1.ge1ae23dd-2 (+27 0.01) Simple backup/snapshot system inspired by Flyback and TimeVault. CLI version. aur/ba ckintime-cli 1.3.2-2 (+287 1.81) Simple backup system inspired from the Flyback Project and TimeVault. CLI version. aur/backintime 1.3.2-2 (+287 1.81) Simple backup system inspired from the Flyback Project and TimeVault. QT5 GUI version. Like in every distro there are always many more or less "official" repos to install packages and AUR seems to be the main "community" repo for additional software: https://wiki.archlinux.org/title/Official_repositories
This irritated me too. The version in the display name is not used to pull from Git, this in determined by the "source" entry in PKGBUILD and this does not use a version or tag here, only the $_pkgname and $url vars to build the URL to the source code: _pkgname=backintime pkgname=($_pkgname-git $_pkgname-cli-git) pkgver=1.3.1.r1.ge1ae23dd pkgrel=2 url="https://github.com/bit-team/backintime" ... source=($_pkgname::git+$url.git) "man PKGBUILD 5" tells more about the source URL in the section "USING VCS SOURCES"...
It seems to me that the distro maintainer did something wrong in that build script. It is not our responsibility.
From a formal point of view this may be correct, as developer I am happy to get early feed-back as soon as possible to fix bugs timely.

Moin Jürgen, sorry I'm a bit stubborn, narrow-minded and learn-resistant here. ;) Am 23.10.2022 23:51 schrieb BiT dev:
Ah, two versions not four. Just the usual qt/cli separation in two versions. I know that Arch is rolling and doesn't have a major version number. But maybe the 27 and 28 indicates something like the "current stable" and "the previous/old stable"?
This irritated me too. The version in the display name is not used to pull from Git,
We should open a bug report about that at Arch to investigate this further and to get feedback from the distro maintainers. There must be (good) reasons why the do it that way and we should learn that. But IMHO distros shouldn't do that. No matter that there users now offers us with upstream bug reports because they involuntarily and unknowingly do test the latest upstream code in there distros.
as developer I am happy to get early feed-back as soon as possible to fix bugs timely.
I agree and see your point. From my point of view I see two bugs mixed here. At one side the distro specific Arch/AUR package is buggy. That is not our business except for just opening a ticket about that. Can you open a ticket against that AUR package and link it in #1333 please? But because of that bug we luckily received another bug report that indicates problems with our upstream-master code. Every time I read something about "distro" (e.g. the tag "distro-specific") in our Issues I'm confused. In that case I assume that is not for upstream and should thrown back to the distro maintainer and the ticket system there. Maybe this is a good Issue to learn for me why "distro-specific" tag is useful for us. Why? ;) Kind Christian

On 24.10.2022 10:34, c.buhtz@posteo.jp wrote:
Well, different distros have different defaults and conventions. It could be that some problem exists only on Wayland, but not X11. In that case, if a report mentions a Wayland-default distro, we have a hint. Also, there are different conventions about install paths, config locations, there could be different Qt versions etc. And rolling-release distros like Arch and OpenSUSE Tumbleweed are more likely to have the latest versions of python, rsync, Qt etc. So the goal is not to deal with the distro-packaging etc., but to identify failure conditions more easily based on the properties of the affected distros. Cheers, Michael
participants (3)
-
BiT dev
-
c.buhtz@posteo.jp
-
Michael Büker