Akira: Please don't change tags!

[alerque]

Tagging an Alpha release was great! But good release practice starts now. Deleting the tag and re-creating it (or rather deleting it and creating a similar one) was the wrong thing to do, that creates all sorts of messes downstream from broken packaging to git of forks that have tags that don't exist upstream. Just bump the patch release number if necessary and don't stress over it. But the mess made by retroactively tryng to change a tag is worse than just having two releases in quick succession.

[Alecaddd]

Yeah, sorry.
I was just experimenting and I assumed it would have been okay since it's the first one.
I won't do that anymore :sweat_smile:

[alerque]

....and now you have an Alpha release tag that is newer than the release tag of the same semver. So a tag that sorts as older in almost every revision parsing system out there is actually newer.

[alerque]

...and now you just skipped 10 versions! I understand the desire to crank it up to 11, but why did you skip v0.0.2, v0.0.3, v0.0.4, v0.0.5, v0.0.6, v0.0.7, v0.0.8, v0.0.8, v0.0.9, and v0.0.10?

https://semver.org/

[albfan]

@Alecaddd we can go with v0.0.1-alpha2, ... whatever.

We really want to go for 1.0.0 at some point, so all this doesn't really matter.

[Alecaddd]

I was having troubles with the elementary OS release bot.
My bad for the 11 variation, I'll continue with 12, 13, 15, etc for the alpha cycle, aiming for 0.1.0 as Beta.

[alerque]

Thanks for continuing with v0.0.12! Using the zero-dot-zero-dot-N for Aplhas is fine, you can keep counting up in that space as long as you need to.

That's better than v0.0.1-alpha2 because it sorts correctly as newer than other released tags. I'm sorry @albfan but all this does matter, prerelease packaging is already hitting the distro packaging stage. If you biff it now and they have to start using epochs to track your releases because your own versioning is out of order they won't be happy. Also what you do during alpha/beta stages matters because it is a shake down your release process. You want to test and develop your procedures around tagging, how your versioning works, whether your release build process is working, etc. Lots of projects out there are dismissive of these kinds of issues, but when v1.0.0 does roll around you don't want it to be a fiasco because your release process was considered "it doesn't really matter, this isn't the big release yet".

[FabioLolix]

as an AUR packager with a lot of pkgbuilds at hand (150+) I don't care about how many versions do you skip but do it in a consistent manner