I’m looking to do some sort of pre-release, and would love some feedback. This will probably be in the form of a nightly/weekly build, and marked a “pre-release” on GitHub releases.
The goal here is to get wider testing of Atuin before releasing a new version, without depending on people building from source.
What I’m interested in knowing is
Would you run a pre-release?
Other than providing a binary download on a release page, is there any other delivery method that would make this easier?
I’m vaguely considering the possibility of a self-updating binary, though this would need to be a feature that can be disabled easily (off by default) - for package managers.
I can certainly do tests. Both nightly and weekly is fine by me, whenever is needed. I myself have no problem compiling from source, and I would consider it the simplest yet most flexible solution. However, I agree that that is not the case for all the potential testers.
I personally feel that, especially for pre-release testing, one should have control over which version is run and tested. If the binary self-updates, one might not even realize the update was performed, and that might cause all sorts of issues, I presume. Grabbing binaries from the release page would be the second-best approach, in my opinion. It is more work for the testers than a self-updating binary, but in the case of pre-release testers, I feel like they should consciously test for specific features/updates/changes (as requested by you through some kind of communication channel, for example) on a specific app version.
If having some of us do a manual monkey testing (just using the pre-release version as if it was a normal release, without explicitly trying/testing the new features/changes) is of interest too, then the self-updating binary might be useful indeed. In my case, I could automate monkey testing by using atuin-git AUR package (grabbing always the latest commit on master and compiling). But this is just one step above compiling from source manually, especially for nightly releases. If something like this could be achieved on other platforms (and other distros), monkey testing would be probably easier. For Linux, maybe a pre-release of Snap (which self-updates) of Atuin could work? Easier than having numerous package versions for each Linux distro.
This is mostly what I’m interested in here. Having a few people using a set version (that’s known to be potentially unstable) as a daily-driver. The release notes may call out specific features that would be great to try, but it’s more passive than “please try xyz, and lmk how it goes”. I’d like to weed out issues with certain setups far sooner, and get feedback on experiments more quickly
Understood. Then, easy updates would highly improve the testers comfort and their willingness to actually update regularly, I imagine.
From a quick glance, self_update looks interesting, too. Not sure how well it would work on MacOS and Windows, but for Linux it could be an all-in-one solution, too.
How would this work with the actual self-updating, then? Because running manually atuin update each day for nightly releases, for example, might be difficult to remember unless you truly want to help test Atuin, which I am not sure how many people would be willing to do. It would be great if there was a mechanism in place which would run the command each day automatically. Either as a part of Atuin, or as an external script (something like a systemd timer for Linux) which could run atuin update automatically. Or something even simpler, probably. These scripts can be either provided by Atuin, or they can be kept up to each tester to implement as they see fit.
I also think downgrading and stopping the auto-update would have to be an easily accessible feature. Extreme case would be something like
I could run a pre-release version on at least one of my machines.
Auto-updates would be the way to go IMHO. For a one-off I can build main myself but rebuilding regularly isn’t that practical.
It would also help to have callouts of what’s new and what kind of testing you need in addition to just using it.
Probably that would work better as forum posts
Thinking so far I’ll start with weekly (well, roughly weekly) releases, they’ll be on GitHub releases + posts right here. That way I can mention what’s changed + what can be tested.
Binaries will be built by the release workflows, so there’s no building from source required.
In the meantime I’ll look into self-update, but it won’t be totally automatic for a little while at least.
For weekly-ish releases, I think it is entirely fine if there is some manual work involved. I think that that is still acceptable by most willing testers.
Is it OK if I build from source from the latest master (or the release commit) instead of grabbing the pre-built binaries? It is ultimately faster for me. I believe there should be no issues originating from the different build environments. If not, I can work with the pre-built binaries without any complaints, too.
I’d run a pre-release, and a weekly release isn’t too much effort to do manually but I can’t guarantee that I’d remember / get around to an update weekly :-/
