I know 24.04 will be another Ubuntu LTS. In the stats for the forum, I can see a lot of people still clicking on posts about 1.93 (e.g., from Ubuntu 20.04 LTS).
When do you think we’d need a 1.99 or 2.0 release to provide you with enough time for the LTS freeze? (including maybe a week or two for last-minute bug fixes like 1.98.1 and your recent bug reports on GitHub)
Ubuntu is usually quick to pick up the Debian package. They already have builds of avogadrolibs 1.98.1-2, 1.98.1-2 : avogadrolibs package : Ubuntu. So I expect they’ll catch 1.98.1-3 and the corresponding avogadro package in the next day or two.
So if feature freeze is Feb 29 then early February at the latest Feb 10 should give them enough time, assuming there’s no interference from Qt packages (I’ll try Qt6 builds once 1.98.1 reaches testing).
This “fast” build is for the ubuntu “proposed” universe. We can watch the progress of 1.98.1 at avogadrolibs package : Ubuntu to see how long it will take to get to “release” universe, which is where you really want it to appear. There’s a risk that will take longer than we’d like.
If, by chance, I get everything working with Qt6, there will definitely be some posts on here. I’d rather target that for 2.0 … we use regex pretty heavily. Between those changes and packaging, it’ll take a while.
For .deb accepted to Debian testing, the automatic share and update to its relatives (e.g. Ubuntu, Kali, Raspian, Devuan) can complete in less than a week if the receiving distribution equally has a branch testing (e.g. Raspian) or is rolling (e,g. Kali). Thus, with avogadro 1.98.1-1 accepted by [2023-11-27 Mon] into Debian’s unstable (link to the package tracker), it could be in Debian testing by Sunday, and from there within a week in the proposed launchpads of Ubuntu Noble, too.
Assuming the package 1.98.1 uploaded for Debian testing does not contain an error (and as few as possible warnings), then the almost same stack of files can be used to eventually provide a backport which provides a distribution already published as stable/LTS a newer version of the program. Specific to Debian: this only requires dch --bpo, adjustment of the /debian/changelog file to point to stable-backports, and dpkg-buildpackage -us -uc -sa -D to prepare this upload. (And the upload to yield the backport can take place just after the upload for the version aiming branch testing as temporarily deferred
Because Ubuntu equally allows updates by backports and Avogadro2 already is introduced to the current Ubuntu 22.04 LTS, my suggestion is to keep the dates when Ubuntu 24.04 LTS enters freezing in mind, but prioritize a well rounded, stable Avogadro2. (And perhaps consider a backport of 1.981 to Ubuntu 22.04 LTS).
The hourly update by repology.org about Avogadro2, excluding unsupported Linux distributions (i.e. which no longer receive updates) is the one below:
Snap packages might be an option if snap already is installed and used for other applications. Similar to docker, if this infrastructure is necessary to support only Avogadro as sole application, I would choose the other road (Frost) and use the AppImage instead.
Yep. But I can see on the forum here that there are ~25 visits per day for “Avogadro 1.93 Export Molecule Doesn’t Work” and another ~20-25 visits per day to an issue with Open Babel and 1.93. A release made back in Feb. 2020.
(For reference, the threads about installing DLL for Windows builds get ~50-70 visits per day.)
So while my focus is on making Avogadro2 as good (and stable) a release as possible, I’m also aware that Ubuntu LTS releases are very influential. Whether users are unwilling to install newer packages or Flatpak / AppImage or unable (e.g., they are not allowed to install packages) 1.93 is still out there.
Thus, I’m inclined to make sure there’s some sort of stable release by the end of January.
I’ll leave backports, etc. up to @RizzerOnGitHub … although I’m sure Debichem is always happy to accept help.
Certainly backports are are bit of a nuisance logistically. Generally my busyness plate is full, I try not to add to it by putting backports on top of the workload. Though --bpo might ease some of the pain.
Though Qt6 is not necessary to have sorted by 24.04, I do think it is critical to get Wayland support fixed by 1.99.
Ubuntu has Wayland as the default session since 22.04, but I suspect the number of improvements to the implementation in the last two years will mean a significant increase in the number of users migrating. Fedora is even getting rid of the option of an X11 session (though keeping XWayland) completely from Fedora 40 (spring, so will include Avo 1.99), and it will likewise be gone from RHEL.
Running Avogadro works fine on a Wayland session but only if it is started from the command line, and with -platform xcb to run it with XWayland.
Unfortunately, what I imagine happens instead, and what will only happen more frequently after 24.04: a Linux user (non-technical, doesn’t know what Wayland is) who grabs Avo from the repo to check it out and starts it under Wayland is greeted with an app that just doesn’t work graphically, and will then probably be scared away for life
So even if Wayland isn’t actually fixed, we should at least put in a temporary fix and somehow make it so that Avogadro only launches using XWayland (i.e. -platform xcb is “passed” by default).