SLiM 4.2.1 fc 3 release process

[bhaller]

Hey folks. Sorry -- another bad bug is forcing another roll of SLiM. Aargh. This bug is only in SLiMgui, but it is a very common crash, so it needs to be fixed. To keep this simple, especially since it is only a SLiMgui bug, we're going to do this as a patch of the 4.2.1 release -- 4.2.1 fc 3, now -- rather than going to 4.2.2; that way installers that do not include SLiMgui (conda, etc.) don't need to be updated at all, and the doc, reference sheets, etc., do not need to be re-rolled at all -- no version number increment. I'm presently teaching a workshop in Stockholm, so I want to keep this patch as simple as I can.

The old v4.2.1 tag has been removed; it had the comment Version 4.2.1 final candidate 2. A new tag, also named v4.2.1, has been created and pushed, with the comment Version 4.2.1 final candidate 3. (I don't know whether this is the best way to do things, but it seems to have worked for the last patch-release.) I have not shifted the official Release to use that new tag yet; I will do that once the macOS installer is rebuilt and the release is ready to announce (although not all installers will be done yet, probably).

@bryce-carson I have tweaked the SLiM.spec file, incrementing the "Release" to 2 and adding a comment for that increment. Hopefully that is the right thing to have done. :->

So, you all know the drill (and remember, if a given installer doesn't include SLiMgui then it does not need to be updated at all):

• [x] a new conda package (me) -- not needed
• [x] a new macOS installer (me)
• [ ] a new Arch installer (@grahamgower)
• [ ] a new Windows pacman installer (@rdinnager)
• [ ] Linux installers (@bryce-carson)

Stay tuned. Sorry for this; 4.2 has been an unlucky release. The best-laid plans. In hindsight, I made what seemed like a small change that has had unanticipated knock-on effects that have echoed considerably; I ought to have thought harder about that change. :-O

[bhaller]

OK, the Release in GitHub has now moved to the new v4.2.1 tag and contains the new macOS installer. I believe things should now be completely ready for all of you, including you @rdinnager. I'll announce the patched release on slim-discuss once things are a little further along – ideally, all the installers except Windows. Again, remember that installers that do not install SLiMgui probably do not require a re-roll at all, since the version number did not increment (unless they reference the old tag, or contain a SHA hash that will be considered stale, or something like that). Please let me know when you've done your magic, everybody. Thanks!

[grahamgower]

Hey Ben, would you be able to assign a new version number to this release? Maybe v4.2.2? Reusing an existing version number will cause problems. E.g. for Arch the previous package version was slim-simulator-4.2.1.r0.ga5c09cdc-1 and the new one will be slim-simulator-4.2.1.r0.g1f0b162a-1. This means that there is no reasonable way to compare the two and decide which is more recent. So if someone has the older version installed, there's no reasonable upgrade path without first removing the older package.

Note that 4.2.1.r0.g1f0b162a is automatically generated by checking out the v4.2.1 tag and using git describe --long (plus a small regex that isn't relevant here). The -1 suffix refers to the package release number that can be bumped by the packager (i.e. me) in case of a packaging error, so my hands are tied.

[bhaller]

Hey Ben, would you be able to assign a new version number to this release? Maybe v4.2.2? Reusing an existing version number will cause problems. E.g. for Arch the previous package version was slim-simulator-4.2.1.r0.ga5c09cdc-1 and the new one will be slim-simulator-4.2.1.r0.g1f0b162a-1. This means that there is no reasonable way to compare the two and decide which is more recent. So if someone has the older version installed, there's no reasonable upgrade path without first removing the older package.

Note that 4.2.1.r0.g1f0b162a is automatically generated by checking out the v4.2.1 tag and using git describe --long (plus a small regex that isn't relevant here). The -1 suffix refers to the package release number that can be bumped by the packager (i.e. me) in case of a packaging error, so my hands are tied.

Hi @grahamgower. I would prefer not to. I'm teaching a SLiM workshop in Stockholm right now, so I have very little time to deal with this, and bumping the version number makes the release much more complex on my end – the doc has to be rerolled, more macOS targets have to be rebuilt, etc., and I just don't have time/energy to deal with it in the middle of a workshop. (The new release needed to happen immediately because the bug was actually getting in the way of people in the workshop doing what they need to do!)

So, hmm. Can you perhaps pretend, somehow, that there was a packaging error, so that the -1 gets bumped to -2? That would solve the problem, perhaps? Also, let me ask @bryce-carson and @rdinnager – will this also be a problem for your workflows, or is this specific to Arch?

Once the installers are ready, I plan to announce this patch on slim-discuss; I can tell people there that if they have already installed 4.2.1 they should be sure to uninstall and then reinstall to get the patch. People who have not already installed 4.2.1 (most SLiM users, probably; I don't think many people stay on the cutting edge) will just get the patch automatically when they upgrade. That will leave only the people who (a) are on 4.2.1, but (b) are not on slim-discuss. If those people encounter the bug, they will presumably complain, and I can then direct them to the patch update. It's an imperfect solution, but I really don't want to try to go through a full release while teaching the workshop. :-O

Thoughts?

[bhaller]

(Twice as much work for everybody, but I could do a patch of 4.2.1 now, with the disadvantages that entails, and do a 4.2.2 release, of the same code, once I'm done teaching this workshop. I'm not particularly enthusiastic about that option either, but it does exist.)

[grahamgower]

So, hmm. Can you perhaps pretend, somehow, that there was a packaging error, so that the -1 gets bumped to -2? That would solve the problem, perhaps?

No, that won't work. Bumping that number wont change how the versions are compared - i.e. 4.2.1.r0.g1f0b162a-2 < 4.2.1.r0.ga5c09cdc-1. Maybe the Arch package is the only platform with the git hash in the version number like this so maybe it's not a problem for other platforms.

Of course there are always ways around it, but I thought I'd ask since, you know, this is the reason software has version numbers, right?

[bhaller]

So, hmm. Can you perhaps pretend, somehow, that there was a packaging error, so that the -1 gets bumped to -2? That would solve the problem, perhaps?

No, that won't work. Bumping that number wont change how the versions are compared - i.e. 4.2.1.r0.g1f0b162a-2 < 4.2.1.r0.ga5c09cdc-1. Maybe the Arch package is the only platform with the git hash in the version number like this so maybe it's not a problem for other platforms.

Of course there are always ways around it, but I thought I'd ask since, you know, this is the reason software has version numbers, right?

It is indeed the reason why software has version numbers, yes. :-> I'm just not really in a convenient position to bump the version number until at least the end of this week, if not when I get back from teaching SLiM workshops – more than two months from now – and a fix for this problem is needed now, for the next workshop if not for this one. Obviously it would be nice if there were a second developer on SLiM who could also manage the release process in my absence, but, you know, funding. Here we are.

So I'd really like to know whether this will bite only Arch, or also other platforms. Waiting to hear from @bryce-carson and @rdinnager on that.

[bryce-carson]

So, hmm. Can you perhaps pretend, somehow, that there was a packaging error, so that the -1 gets bumped to -2? That would solve the problem, perhaps?

No, that won't work. Bumping that number wont change how the versions are compared - i.e. 4.2.1.r0.g1f0b162a-2 < 4.2.1.r0.ga5c09cdc-1. Maybe the Arch package is the only platform with the git hash in the version number like this so maybe it's not a problem for other platforms.

Of course there are always ways around it, but I thought I'd ask since, you know, this is the reason software has version numbers, right?

It is indeed the reason why software has version numbers, yes. :-> I'm just not really in a convenient position to bump the version number until at least the end of this week, if not when I get back from teaching SLiM workshops – more than two months from now – and a fix for this problem is needed now, for the next workshop if not for this one. Obviously it would be nice if there were a second developer on SLiM who could also manage the release process in my absence, but, you know, funding. Here we are.

So I'd really like to know whether this will bite only Arch, or also other platforms. Waiting to hear from @bryce-carson and @rdinnager on that.

What I can do to make things easier for you is turn the changes in git into a patch over the 4.2.1 sources. I'm not sure if the changes to the existing tag will affect that, but I can manually target the commit that the tag did—er, tag?—and then release it as a new version of the RPM.

The RPM changelog can reflect that this is what is happening, and it shouldn't affect my process other than generating the patch itself. I think Git even has a command for it.

Once the new release does come around the RPM will simply target that again.

I might also be able to treat the current revision as 4.2.1-2—or 4.2.1-3?—and turn the crank even faster. I'll ask some more knowledgeable people if that might have any consequences, but I doubt it would.

I think I did as much not long ago with the RPM anyway.

[bhaller]

Hi @bryce-carson,

What I can do to make things easier for you is turn the changes in git into a patch over the 4.2.1 sources. I'm not sure if the changes to the existing tag will affect that, but I can manually target the commit that the tag did—er, tag?—and then release it as a new version of the RPM.

The RPM changelog can reflect that this is what is happening, and it shouldn't affect my process other than generating the patch itself. I think Git even has a command for it.

I'm not sure what that means, sorry.

Once the new release does come around the RPM will simply target that again.

Or this either. :-O

I might also be able to treat the current revision as 4.2.1-2—or 4.2.1-3?—and turn the crank even faster. I'll ask some more knowledgeable people if that might have any consequences, but I doubt it would.

I think I did as much not long ago with the RPM anyway.

It would be good to do this ASAP. The feedback I've gotten, from both Graham and from you (via email), is that this would be better as 4.2.2. I hear that, and I will try to package up a 4.2.2 release. But I simply don't have time right now, and the next SLiM workshop starts in one week, and I need SLiMgui not to be crashing for the workshop students. I take the train to Copenhagen today; I will see whether I have time, during that train ride, to work on making a proper 4.2.2 release. But for now, please, folks, try to get this 4.2.1 patch process working to the extent possible. Thanks.

[bhaller]

OK, things are going smoothly on the train thus far. To avoid confusion, I'm going to close this issue and start a new issue for the 4.2.2 release. This patch release of 4.2.1 to fix the SLiMgui crash ended up rolling only on macOS. So @bryce-carson @grahamgower @rdinnager, never mind – doing this as 4.2.1 fc 3 was a bad idea, I guess. Sorry for the noise!