Moin Folks, Am 23.10.2022 17:16 schrieb Michael Büker:
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
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.
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...
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.