Awesome: Create a git tag for better version output for builds on master

[blueyed]

What about git tag --annotate v3.5.60 $(git merge-base 3.5 master)?

Re https://github.com/awesomeWM/awesome/issues/1021#issuecomment-235608858 and several other reports of confusion, since currently awesome --version will use v3.5.2- as base.

awesome v3.5.60-1863-gcbda387-dirty (The Fox)

IIRC @Elv13 mentioned v3.5.60 on IRC lately.

[psychon]

'v3.5.60' sounds random and would be the first such tag that we have. I'd suggest to use a name which makes it clear that this is not an official release, but I don't have good suggestions. Also, I wouldn't tag the merge base, because then the tag is also reachable from the 3.5 branch.

[Elv13]

.60 is KDE naming scheme for pre-alpha versions. .70 are alphas, 80 are betas, 90 are RCs. Most applications stopped actually tagging the .60 and 70 back in the SVN days (because SVN tags suck). But then again, they use version strings, not git based autogenerated versions. tag names have to be string comparable (for distribution scripts), so this rules out a lot of possibilities.

I think this kind of versions tags would at least solve our problem. And who cares? A solution, even based on a random convention (what isn't anyway), is better than users complaining over and over and over and over again. It is not like I invented anything. Plenty of projects do that. It is a lot less confusing than the GTK/GNU way of doing this (odd numbers for devs even numbers for stable, but only on the first 2 digit groups, then normal increment for the 3rd one) or the GCC "great idea" of tagging the next .0 the day after the last release was made (download GCC 7.0 today! the official GCC 7 release is expected next spring).

Another scheme include time based releases + LTS releases. Like Chrome or the kernel does. So, basically release master every X number of weeks, keep master stable at all time using the CI (keep a -next branch with all the fun stuff) and put "hard" rolling deprecation rules (avoid hard API breaks for 6 months and display time based deprecation popup ("you have 15 days left to fix this")). The hard part with this is convincing the distributions to allow the rolling. Otherwise it will break the API when users update their distro (hmm, well, like currently...). This is of course better, but puts extra constraints on us and requires "perfect" downstream coordination (all distros, all users, all modules maintainers). It also requires users to restart Awesome more frequently than the cycle length (or have some kind of background linter). So it is a little bit complicated for a desktop software.

That being said, I give a +1 for the 3.5.60 tag.

[ibrahima]

'v3.5.60' sounds random and would be the first such tag that we have. I'd suggest to use a name which makes it clear that this is not an official release, but I don't have good suggestions. Also, I wouldn't tag the merge base, because then the tag is also reachable from the 3.5 branch.

Version numbers are pretty arbitrary and like @Elv13 said, at least there's some method to the suggested scheme. The point is just to make a version that won't be hit by normal 3.5 releases.

I'd suggest just tagging master at an arbitrary point in time (maybe HEAD, maybe merge base, maybe merge base + 1). Shouldn't really matter what because releases in the 3.5 series should have a closer/more recent tag than the merge base for 3.6, if I understand how git describe works correctly. I see no problem with just tagging current HEAD, because it's all arbitrary anyway (no one is looking at the "commits since tag" part of the version to determine anything of importance.

[psychon]

merge-base is c855b1babb0b2e8c171e16ea6f40da668d98a372.
merge-base+1 for master would be ceaeaedb5b1cd98b9ae1e04d6011219a3a11e228.
merge-base+1 for the 3.5 branch is 926dd348e437ca1a174d53c215dc1f1aa2af19ca (looks like a cherry-pick of 11f7b5aa3d35a215209e4b59d60b174864e007e8 from master).

So I'd suggest git tag --annotate v3.6.0-alpha1 ceaeaedb5b1cd98b9ae1e04d6011219a3a11e228. No idea what the message for the tag should be. I am suggesting -alpha1 because this makes it intuitively clear that this is not a release, even for people who do not know/expect KDE's versioning scheme. Having the string "alpha1" in there shouldn't really cause problems, because nothing looks at the string, right? (No distro is going to package this). Calling this "alpha1" doesn't mean anything (at least to me). Awesome only ever had RCs and even if this alpha1 means we get more testers and bug reports, that just means that Elv13 hopefully has to wait less time for the new release.

[psychon]

Wait... I'm confused / missed something important. If that thing is called alpha1, it should be a tag for master, not for merge-base+1!

[osleg]

I think he meant for the "next after release".
Anyhow, I think Elv13 idea is better than 3.6-alpha as it's yet not 3.6.

[Elv13]

It can't be 3.6-something. It will create a conflict with the string comparison of the version number. If version >= "3.6" then ... else ... end. 3.6-alpha1 is greater then 3.6, but it isn't.

[psychon]

Which one is "the" string comparison? What is comparing these strings and why? Why does that thing work when it assumes that something is awesome 3.5 which it definitely is?
Put differently: Isn't the thing doing the comparison already broken, because master is definitely not 3.5?

[actionless]

i remember those version strings comparison issues with AUR helpers, ie it wouldn't update the package automatically if it'll think what new version is smaller than already installed one

[Elv13]

On IRC:

[19:20] the version umber is also << what's in apt, so it keeps trying to upgrade it back to the debian version

Using our make package. Can we just act on this, tagging either 3.5.60 or just going to 3.5.95, aka 3.6-alpha1 (but we can't call it that). Looking at the v3.6 milestone, everything in it is either documentation related or in an advanced state of being addressed. It is time. If it was only me, I would just do the 3.6 release (maybe with a couple RCs), wait for complains, then release 3.6.1. It has to stop at some point. Of course there is broken things and possible improvements, there will always be.

[psychon]

We (try to) not break API in minor releases, so the few issues which sound like they need API changes keep me away from something like this (#1180? #1001?).
I'll create an API-freeze milestone. When that one is handled, I don't mind an alpha release (but wouldn't it be nice for users if #967 were also done before alpha?).

And I still don't understand why a tag cannot be called 3.6-alpha1. Which string comparison would break?

[actionless]

IIRC it's using sort -V under the hood, i think apt is using some similar logic

UPD, example:

$ echo '3.6
  3.6-alpha1
  3.5.9
  3.6.0' | sort -V
3.5.9
3.6
3.6-alpha1
3.6.0

[Elv13]

This is no longer an issue