SLiM 4.1 release process

[bhaller]

Hi folks. SLiM 4.1 is ready to release! This issue is to manage its rollout. It has been tagged in git (v4.1). Things to do:

• a new conda package (me)
• a new macOS installer (me)
• a new Arch installer (@grahamgower)
• a new Windows pacman installer (@rdinnager)
• our first AppImage installer! (for SLiMgui only) (@bryce-carson)
• other Linux installers (@bryce-carson)

I'm not sure whether you'll be able to check off things when they're done, but anyway you can post about progress on this issue and I'll check things off. Thanks!

@rdinnager, I have this vague memory of some step that you needed me to take before you can turn the pacman crank, but I don't see it in my notes. Let me know if there's something you need from me. :->

[bhaller]

The conda build has just completed for Linux, macOS, and Windows; it is now live.

[grahamgower]

Thanks Ben! The Arch package is updated. https://aur.archlinux.org/packages/slim-simulator
FYI, I can't tick the checkbox in your comment.

[bhaller]

Thanks Ben! The Arch package is updated. https://aur.archlinux.org/packages/slim-simulator
FYI, I can't tick the checkbox in your comment.

Thanks Graham! Yes, maybe only I can do that? No idea why. :-> Now ticked.

[bryce-carson]

Yes, maybe only I can do that? No idea why. :-> Now ticked.

That is how it works, yeah. The checkbox is just a fancy rendering of the markdown in your comment. There are other options for completing "tasks" that others can complete with the privileges they have.

[bryce-carson]

Hi folks. SLiM 4.1 is ready to release! This issue is to manage its rollout. It has been tagged in git (v4.1). Things to do:

Hi @bhaller, see #414 for progress on the AppImage. It's done, but the Git SHA-1 is not appearing. If that's not bothersome, I can release it. The new RPMs are published on Copr and are generally available now.

You can update the checkbox in your opening comment if you'd like (4 of 6 tasks! Micro-achievements!):

• our first AppImage installer! (for SLiMgui only) (@bryce-carson)
• other Linux installers (@bryce-carson)

[bhaller]

Hi @bhaller, see #414 for progress on the AppImage. It's done, but the Git SHA-1 is not appearing. If that's not bothersome, I can release it. The new RPMs are published on Copr and are generally available now.

See my comment on #414 and let me know what you think. If that problem is hard to track down, then I don't care enough to delay the release. So let me know, and we'll move forward as you wish. I'm still lining up ducks on my end, so you're not delaying the release by futzing around with the SHA-1 stuff.

[bhaller]

@bryce-carson Realized maybe I should've tagged you in my previous comment for visibility. What do you think? Is it time for me to merge your PR, or are you still doing things?

[bryce-carson]

@bryce-carson Realized maybe I should've tagged you in my previous comment for visibility. What do you think? Is it time for me to merge your PR, or are you still doing things?

That's alright, no worries.

Yeah, go ahead and merge it now.

I'm rebuilding the AppImage on an older base operating system, because I built in on Fedora 38 so it was dynamically linked against too new of a libstdc++ (one of the few things that it doesn't statically compile with).

Flatpak is a little more containerized, whereas AppImage is supposed to be "easy" for upstream to distribute. I've seen both ends, and AppImage was certainly much easier. I just need to do the rebuild and then test on Xubuntu again and we should have it all good to go for release. The README is ready, however.

[bryce-carson]

@bhaller, sorry for the second comment:

The current AppImage released on my fork will work on newer systems, it just won't work on the oldest ones we support (Ubuntu 22.04, right?). Rebuilding the binary against an older target before bundling it as an AppImage will allow it to work on older and newer systems; at that point I'll edit the release on my fork and change the asset.

[bhaller]

Hi @bryce-carson. There's a merge error on the PR, I commented over there. Regarding what you commented above, ok, to the extent that I understand this stuff, sure. I'm glad that AppImage is proving to be easier; Flatpak seemed like kind of a nightmare. Re: older systems, I think maybe technically we support as far back as 18.04 LTS with Qt 5.9.5, but I couldn't care less if AppImage works on such systems. People on ancient systems like that can always build from sources. For the AppImage, support what seems good/convenient for you; 22.04 LTS sounds fine to me. Thanks!

[bhaller]

I've made the macOS installer, yay! (Quite a complex process, with code-signing and notarization and stapling... and Apple changed the tools for those steps since the last time I did it, too...). The production process for the manuals is also complete, etc. So I'm mostly ready to go. The announcement itself still needs to be written, and the Linux installer stuff is not quite ready, so I'm going to go to bed now and finish this tomorrow morning. Probably better to finish it up after a night's sleep anyway. So, @bryce-carson, please leave comments indicating the final state of things when you yourself go to bed, thanks. :-> @rdinnager haven't heard from you, would be good to get the pac-man crank turning since it takes so long to complete, thanks. Good night all.

[bhaller]

(You got me before I actually walked away, @bryce-carson. With the PR now merged, I checked the two boxes for Linux above; I guess your end of things is done? Or maybe you're still building for the older Ubuntu or something? Anyhow, let me know if I ought to uncheck those boxes again, but my impression is that you'll be ready for the announcement by tomorrow morning. :->)

[rdinnager]

@rdinnager, I have this vague memory of some step that you needed me to take before you can turn the pacman crank, but I don't see it in my notes. Let me know if there's something you need from me. :->

Yes, I just refreshed my memory on this as well ;) . I can't submit the new version to pacman until the release has been made on github. That is because pacman uses this URL: https://github.com/MesserLab/SLiM/releases/download/v${pkgver}/SLiM.zip to get the source for building. But I just had a look at the conda installer and see that it uses https://github.com/MesserLab/SLiM/archive/v{{ version }}.tar.gz . So in theory I could change the URL in pacman to use https://github.com/MesserLab/SLiM/archive/v${pkgver}.zip ? I guess I originally assumed using the release URL would be more stable? What do you think @bhaller , should I change the URL to the git tag, or keep it pointing to the release?

[bhaller]

@rdinnager, I have this vague memory of some step that you needed me to take before you can turn the pacman crank, but I don't see it in my notes. Let me know if there's something you need from me. :->

Yes, I just refreshed my memory on this as well ;) . I can't submit the new version to pacman until the release has been made on github. That is because pacman uses this URL: https://github.com/MesserLab/SLiM/releases/download/v${pkgver}/SLiM.zip to get the source for building. But I just had a look at the conda installer and see that it uses https://github.com/MesserLab/SLiM/archive/v{{ version }}.tar.gz . So in theory I could change the URL in pacman to use https://github.com/MesserLab/SLiM/archive/v${pkgver}.zip ? I guess I originally assumed using the release URL would be more stable? What do you think @bhaller , should I change the URL to the git tag, or keep it pointing to the release?

Hi @rdinnager! Ah, hmm. Well, here's the difference. The tag gets set each time I have a final candidate; so the tag v4.1 exists now, and points to final candidate 1 (which looks like it is good). If there is a problem with that final candidate that is discovered during the release process, the v4.1 tag would be removed, and redefined to point to final candidate 2 once that exists, etc.; so it is not guaranteed to stay the same while the release process is rolling; it is a moving target. Once the release is announced, the v4.1 tag is frozen, pointing at whatever final candidate became the release, and the release is declared as a "release" on GitHub, making it official; if there is any problem with the release after that point, a new tag (and a new SLiM version) would be made, releases never get changed after they are announced.

So, I don't know how that interacts with pacman's expectations. For conda, if a final candidate was rejected/replaced I'd restart the conda build with the new final candidate, incrementing their internal build number to let conda know that it needs to rebuild for that version even though the tag name is unchanged. If doing that sort of thing for pacman makes sense too, then we could switch it over, sure. That would allow us to see problems with the pacman build before the release is frozen – problems which might cause us to reject/replace a final candidate. It also lets us start the pacman crank earlier in the process, which would be nice. So I think it's a good idea for both of those reasons, probably?

In any case, I expect to announce 4.1 and freeze the tag later this morning, so for this release the question will soon be moot. :-> But if you want to switch pacman over to the v4.1 tag now, as you propose, I'm all for it.