This has come up before (and corrected, after a code review) but since Konsole isn't the only application concerned I'm logging a ticket for it: I maintain a semi-official MacPorts packaging tree for quite a few KF5 projects, and a considerable number of those ports (packages) are based on snapshots taken from the project git repos - if possible the master branch. I rely on `git describe` to get a representative versioning for those ports. Where necessary I add git tags myself, but it would be great if the upstream version tags could be set in such a way that the `git describe` returns a sensical value for the master branch too. That is: something in the form YY.MM.NN-commitNr which: - increases monotonically - ideally corresponds to or reflects the current stable release - at least corresponds to the version reported by `foo --version` and the KAbout data. This tends to work well enough for most projects, but for some like konsole that has not been the case for a while now: - `git describe` returns v17.11.90-110-ge2184aef on the master branch - it returns v17.12.1-2-g5f0eea61 on the 17.12 release branch - `konsole --version` returns 18.03.70 For comparison, okular's git log shows this: ``` commit e7f90332eaff404fbe03be814c94b5c4625542e2 Author: Albert Astals Cid <aacid@kde.org> Date: Thu Jan 4 18:50:10 2018 +0100 GIT_SILENT Upgrade KDE Applications version to 17.12.1. ``` (though apparently the 17.12.1 tag was set in commit 6ed35fcca3950a54dd5dbd80b90ecd7761467692)
i don't understand your problem. You'll have to be more concise on whta you want, but honestly, you want tags, just use the tags we have. And a bug against konsole is the worst place to discuss how our releasing procedure happens.
What is not clear or concise about this? - ideally corresponds to or reflects the current stable release The goal is 1. to have an official, unique and monotonically increasing version number to use for ports built from a given commit in git repo, 2. that this version number fits in with the most recent (applications|frameworks|plasma) release version published before that given commit. It should certainly not be inferior/older. Point 2 is esp. important in the cases where I provide a release and a "devel" port. This does not concern those projects that have their own versioning, like KDevelop or digiKam, but those that follow the standard (applications|frameworks|plasma) versioning. I *can* use the tags you add most of the time, but not always. Who would understand that Konsole 17.11.90.110 is chronologically equivalent to 17.12.1.2 ? And who understands why that same version identifies itself as 18.03.70? Feel free to change the ticket "product".
> Who would understand that Konsole 17.11.90.110 is chronologically equivalent to 17.12.1.2 ? those tags don't exist.
I'm closing the bug here, if you want to improve our release process, come and discuss it on the release-team mailing list.
I'm reopening this because it's not just a generic issue, there is also a tagging or even versioning problem with Konsole that should be resolved (however minor). The main branch should carry a v18.03.70 tag. I set one locally a few weeks ago on the commit that first mentioned the 18.03.70 version (7f7ed40d1ca6d8578bd41dc3199ce3d68a05a667), but that tag is now hidden by the more recent 17.11.90 tag. This is something that ought to be figured out upstream. > > Who would understand that Konsole 17.11.90.110 is chronologically equivalent to 17.12.1.2 ? > > those tags don't exist. That's because they're not tags. Please read more carefully what people write. Everything needed to understand where those versions come from is in the original message, it's not rocket science. `git describe` will find the most recent tag that is reachable from the current branch, determine the number of commits since that tag, and construct a string of the form $tag-$numberOfCommits-g$commitHash Converting this to a version like 17.12.1.2 is trivial, logical and unambiguous.
Please next time think twice before deciding to waste my time and then deciding you don't want to include me in the discussion again. > The main branch should carry a v18.03.70 tag. No such tag exists, so can you please explain why that should happen?
Apologies for having included aacid, that was clearly a mistake I won't make again. Answering to the Konsole maintainers: > konsole --version konsole 18.03.70 That should be reason enough to add a v18.03.70 tag. IMHO it just doesn't make much sense to use tags that correspond to versions if you don't do it systematically (like the vast majority of other KDE projects do).
You really need to stop unsubscribing me, it's extremely impolite. 18.03.70 is a "developing version", it doesn't exist, so there can't be a tag for it, tags are "a fixed point in the code when a version was set", and there's no fixed point in code that represents 18.03.70. This is not exclusive to konsole, all of the KDE Applications repositories are like this, so as said, if you have a problem with how our release story works, bring it up in the release-team mailing list.
You really need to stop trolling here if you don't want to be part of the discussion. You don't agree, fine, that makes this a matter between the Konsole authors and me, and unsubscribing you is nothing more than an attempt at preserving your so precious time. Please stay out of the discussion from now on. > 18.03.70 is a "developing version", it doesn't exist, so there can't be a tag > for it, tags are "a fixed point in the code when a version was set", Wrong, there's a clear point where the project started reporting version 18.03.70 , and it's not just in my imagination that this called a version: commit 7f7ed40d1ca6d8578bd41dc3199ce3d68a05a667 (tag: v18.03.70) Author: Albert Astals Cid <aacid@kde.org> Date: Mon Nov 13 08:59:20 2017 +0100 GIT_SILENT Upgrade KDE Applications version to 18.03.70. diff --git a/CMakeLists.txt b/CMakeLists.txt index 02f5e82a..5f3e1a8f 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -1,8 +1,8 @@ # Konsole project # KDE Application Version, managed by release script -set (KDE_APPLICATIONS_VERSION_MAJOR "17") -set (KDE_APPLICATIONS_VERSION_MINOR "11") +set (KDE_APPLICATIONS_VERSION_MAJOR "18") +set (KDE_APPLICATIONS_VERSION_MINOR "03") set (KDE_APPLICATIONS_VERSION_MICRO "70") set (KDE_APPLICATIONS_VERSION "${KDE_APPLICATIONS_VERSION_MAJOR}.${KDE_APPLICATIONS_VERSION_MINOR}.${KDE_APPLICATIONS_VERSION_MICRO}") There isn't a more "fixed point in code" that represents 17.12.1 or any other released version: a version upgrade is always a single point in time regardless whether it's a release or a development version. I don't care what form tags take, so there must be any number of ways project authors can tag branches which are not used in the release "story" without causing confusion there, and while still keeping a logical link between a given point in the commit history and a version reported from inside the application. Ideally the application would report a more fully qualified version itself that indicates from which snapshot it was built, but that's a separate issue (cf. patch review D8158). Being able to put a local version on your install or packaging that's based on a version obtained directly from git is the next best solution. So, Konsole author(s): please consider adding a master branch tag for 18.04.whatever whenever that "version" appears and if necessary.
Or consider following KDevelop's approach: - current release version is 5.2.1; `git describe` returns v5.2.1-45-gbda9fd5a29 in the 5.2 release branch - the version used in the master branch is 5.2.40, for which there is no tag. However, `git describe` returns v5.2.1-368-gb4934d31d4 in the master branch. This is perfectly usable too as it clearly shows that the master branch is well ahead of the release branch. It is even preferable because it allows to continue merging commits between the master and release branches AND to have 5.2.2, 5.2.3, ... commits before moving on to 5.3.0 . I cited Okular earlier on, where `git describe` does return a sensical value in the master branch that relates it correctly to the release version. The project itself uses a completely different versioning which is weird but unlikely to lead to ambiguity since it is so clearly independent from the collective versioning.
We don't tag branches, we tag releases. Konsole is part of KDE Applications; we either change all of them, or none, but not Konsole alone. You have been asked twice to bring this up on the KDE release mailing list, but if you ignore what people tell you, you should not be surprised by people's reaction.
I'm not subscribed to that ML, and not really interested in adding yet another list to my collection. And even the initial reactions did nothing to motivate me either. Kate is also part of "KDE Applications", right? ``` > (cd kate-git ; git checkout master ; git pull ; git describe) v17.12.1-40-g2641fc835 ``` so this repo is wrong too because it returns a sensical value? I'll say it once more, I wouldn't have created a ticket here, for Konsole, if something wasn't different about the project.