search

MesserLab / SLiM

SLiM is a genetically explicit forward simulation software package for population genetics and evolutionary biology. It is highly flexible, with a built-in scripting language, and has a cross-platform graphical modeling environment called SLiMgui.
https://messerlab.org/slim/
GNU General Public License v3.0
160 stars 30 forks source link

SLiM 4.1 release process #415

Closed bhaller closed 9 months ago

bhaller commented 9 months ago

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:

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 commented 9 months ago

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

grahamgower commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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!):

bhaller commented 9 months ago

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 commented 9 months ago

@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 commented 9 months ago

@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 commented 9 months ago

@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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

(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 commented 9 months ago

@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 commented 9 months ago

@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.

rdinnager commented 9 months ago

@bhaller Thanks for the clarification. Given that I think we should leave it as the release URL. The pacman system is a little more controlled than conda. The build happens after I submit a pull request, but each PR has to be reviewed by someone before it gets merged, which is why it can take a little while sometimes. If we used the git tag URL, and then it changed before the official release, I would have to make another PR to get it it to build again, which would mean another review each time. For this reason, they also ask that packages do not get updated too often, so I think to respect this we should wait until the final release is ready so that we just have to submit once for each release. I should be able to get the PR in very quickly once the release is out. I have already made the necessary changed in the build code, I just have to wait for the final version to get the SHA-256 and then I can submit it. Ping me when the release is up and I'll get right on it.

bhaller commented 9 months ago

I see. Sounds good, thanks @rdinnager!

bhaller commented 9 months ago

The decision has been made with @bryce-carson to move forward with the release despite issues with the AppImage installer. A little cleanup of the GitHub install info is needed, and then the release will proceed. Stay tuned.

bryce-carson commented 9 months ago

The decision has been made with @bryce-carson to move forward with the release despite issues with the AppImage installer. A little cleanup of the GitHub install info is needed, and then the release will proceed. Stay tuned.

Which install info?

bhaller commented 9 months ago

The decision has been made with @bryce-carson to move forward with the release despite issues with the AppImage installer. A little cleanup of the GitHub install info is needed, and then the release will proceed. Stay tuned.

Which install info?

I just emailed you about that @bryce-carson. :->

bryce-carson commented 9 months ago

@bhaller, I'm going to go with a new, more maintainable format for the installation instructions on GitHub. What do you think of this summary view, followed by a listing? It's the easiest way to move forward, in my opinion.

The following sections summarize what methods for acquiring SLiM (and SLiMgui) are available, and whether they are community maintained or official (all but the macOS installer are community maintained).

Binary packages

OfficialCommunity
macOS
Linux
Windows

Installation scripts

Community
Linux

Guides

Community
Windows
bhaller commented 9 months ago

Hi @bryce-carson. Distinguing between the different types of installation procedures seems helpful, sure. I think I'd get rid of the "official" vs. "community" distinction though. SLiM is a team effort; I'm part of the team, you're part of the team. I'm not sure how that distinction is helpful for the user who is trying to sort through the information – how would it affect their decision about what to do next, really? And I don't really agree with it from the perspective of this being a team effort; over time I'd like SLiM to become even more of a team effort, and so I don't want to start drawing lines like this, really. Does that work for you?

bhaller commented 9 months ago

And, pondering this @bryce-carson, I think I'd make the primary axis of organization be the platform, because that's how people will want to approach it. People will say "I'm on macOS, what installation options are available to me?", not "I'm hoping for a binary installer, what platforms are those available for?" So I'd organize by platform, and show the options available for each platform, maybe?

bryce-carson commented 9 months ago

People will say "I'm on macOS, what installation options are available to me?", not "I'm hoping for a binary installer, what platforms are those available for?" So I'd organize by platform, and show the options available for each platform, maybe?

Hi @bryce-carson. Distinguing between the different types of installation procedures seems helpful, sure.

I think I'd get rid of the "official" vs. "community" distinction though. SLiM is a team effort; I'm part of the team, you're part of the team. I'm not sure how that distinction is helpful for the user who is trying to sort through the information – how would it affect their decision about what to do next, really?

We do mention in the manual regarding some security stuff (read our shell scripts kinda thing; don't trust us). I think you do make an important point, however. Just because we're not part of MesserLab at Cornell doesn't mean we aren't contributing useful or "official" means and methods.

I'll remove the official versus unofficial distinction in the PR to update the README (and include the link to the Arch package, since I forgot that).

bhaller commented 9 months ago

@bryce-carson Sounds good. Let me know when it's ready to merge. I'll do the release right after merging; everything else is ready. Thanks!

bryce-carson commented 9 months ago

@bryce-carson Sounds good. Let me know when it's ready to merge. I'll do the release right after merging; everything else is ready. Thanks!

I'm making the PR now. Woohoo!

bhaller commented 9 months ago

@rdinnager The release is now up on GitHub: https://github.com/MesserLab/SLiM/releases/tag/v4.1. Should be ready for you to kick off the pacman crank. Let me know if you need anything, and please let me know if you need anything from me. Thanks!

bhaller commented 9 months ago

The release is announced here: https://groups.google.com/g/slim-discuss/c/9P3KoPEYpDg. Thanks everybody!

rdinnager commented 9 months ago

@bhaller I submitted the PR for the pacman update last night and it was quickly merged and when I woke up this morning I saw the build has completed and should be available to install via pacman now: https://packages.msys2.org/package/mingw-w64-x86_64-slim-simulator?repo=mingw64 . So you can check it off the list!

bhaller commented 9 months ago

@rdinnager Wow, their review was so much faster than previous times! Thanks! Closing this issue now, the 4.1 release is finished!