1.17 roadmap: 1.18 release date too late for Ubuntu 24.04 LTS inclusion #8187
Comments
pehjota
added
the
Enhancement
|
It was originally planned for February, but it was pushed back a month to give more time for translators after we needed to delay the string freeze by a month to address other issues, so it's not able to be moved back into February at this point. For 1.20 it'd probably be good to leave a spare month or two so it doesn't keep happening though. |
|
Ah, understood. So then unfortunately 1.16.11 (unless 1.16.12 is released before 1.18.0, which I assume not) will be the only version of wesnoth in Ubuntu 24.04 LTS for the lifetime of the release (likely to be supported through end of May 2029), since I assume 1.17 probably shouldn't be packaged yet (development version, incomplete translations, etc.). Are there are any fixes yet in the 1.16 branch you think are worth backporting to 1.16.11 for inclusion in Ubuntu 24.04, or do you expect any? Feel free to let the team and/or me know if any come up before about mid February. |
February 18th is currently planned to be the RC1 release, which essentially means "if nothing critical is found, this will essentially be 1.18.0", so it might be fine to use that? It would still be called 1.17.26 which I suppose might be confusing, but maybe better than sticking with 1.16.
Honestly, not really. 1.17 is already where 99% of development effort is focused so maybe there'll be a couple fixes in 1.16 beyond the ones you're backporting from 1.17, but that'd probably be it. I think https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/2033222 is far more important than anything we're likely to do with 1.16 at this point, if there's anything you'd be able to do to help with that. |
|
@pehjota This might sound strange, but do you consider snaps to be a good default packaging mechanism (or delivery mechanism) for Ubuntu? I've seen it it being taken as controversial or simply wrong (and I was of the same opinion myself a while ago). However, an alternative point of view is that it's simply always better to move "isolated" pieces of software such as games or certain apps to a more portable packaging and execution mechanism such as snaps. Do you think it's a viable strategy to slightly discourage the use of the apt and encourage the use of snaps for Wesnoth on Debian and Ubuntu? These are at least some thoughts that I have when I think about the situation |
|
Wesnoth already has a flatpak available since it's the default pretty much everywhere else, so we've avoided also creating a snap just for the sake of Ubuntu so far. |
|
The message above comes from personal experience of using apt-packaged games on Debian and Ubuntu. Things I've encountered:
|
|
@Pentarctagon gotcha; seems like a reasonable trade-off for me. (Between maintenance/complexity and covering the ground well.) |
Good to know. Sounds like it'll probably be missing some translations though? I guess if both 1.16.11 and 1.17.26 are available in Ubuntu 24.04, users would have a choice between either fully translated or newest.
That's about what I figured. I'll try to keep an eye on the 1.16 branch.
Ah, yeah, that's not a great user experience. As Rhonda says, the problem is that wesnoth-1.16-core provides the executable and therefore also the .desktop and .appdata.xml files, but by design the way the packaging is split (so users can choose to install only a subset of campaigns), the -core package with the executable doesn't pull in all the campaigns (the higher-level wesnoth-1.16 metapackage depends on everything). It's a tricky issue, but maybe the executable's package could just "Recommends:" all the campaigns (which by default installs them, unless the user tells APT not to install recommended dependencies). I'm not sure what manual AppStream data adjustments Rhonda is suggesting; I'll ask. |
|
For multiplayer, if there are a lot of users on 1.17.26 then which other versions does that share a server with? It probably depends on whether there are any last-minute bugs that need an incompatible fix before 1.18.0 releases. |
|
1.17.26 is RC1, so it would use the same add-on and MP servers as 1.18. |
|
Good question @stevecotton, thanks for bringing that up.
Note that since Debian's wesnoth maintainers upload a new source package for each release branch (wesnoth-1.14, wesnoth-1.16, etc.) to allow users to pick and co-install different versions, and all new source packages go through a review queue (which can take a month or longer), it's a good idea to leave at least two or three months spare, to allow for a delayed release as well as delayed review and inclusion into Debian. (I was about to link to the current queue and write a Perl script to calculate the age of packages that recently left the queue to estimate the current median lead time, but the Debian FTP masters Web site just happened to go down, ha. I'll try it again later.) |
|
Back up, here's the queue. The in and out RSS feeds only have five packages in common, so if I correctly understand the dates in the feeds, most of those took 0 days to process, one took 2 days, and one took 56 days. But there are some that for whatever reason have been sitting in the queue for months. That was less useful than I hoped. Looking at when |
|
Putting out a new stable release right around Christmas/New Years would be a bad idea. |
|
By suggesting December (or November?), I was including about three spare months to allow for release delays and Debian's NEW queue (so assuming the release might actually be delayed until early January or so), but yeah, fair enough. If there's at least a Beta or RC1 around early January that can be shipped in a package named On that note, would it be appropriate in this cycle to package either 1.17.24 or the upcoming 1.17.25 under the name |
|
As far as I've ever known, our involvement in distro packaging has basically been to just tag releases and throw it over the wall via the packagers mailing list, so I don't really know which version would be most appropriate for Debian to package initially or what that might mean for future updates. |
|
Sorry if I wasn't clear, I'm not asking you to get involved in Debian packaging decisions. What I'm asking is to confirm from an upstream perspective that either 1.17.24 or the upcoming 1.17.25 (both "Beta" versions of 1.18) are likely to remain compatible with 1.17.26 (which hopefully will be in Ubuntu 24.04) and the final 1.18.x (which won't be in Ubuntu 24.04 except via PPA) so that it's appropriate for us to call 1.17.24 or 1.17.25 "wesnoth-1.18" (which is just to start Debian's new package review process early enough to improve the odds that it gets added to Debian in time for us to then get 1.17.26 into Ubuntu 24.04). Specifically, do these Beta releases use the same add-on and MP servers as 1.18, like you said RC1 will? |
|
The RC1 (1.17.26) release is when it will get split off from the current 1.17/master branch. At that point, even though it's called 1.17.26, its git branch will be "1.18" and it will use the 1.18 MP and add-ons servers. So it'd definitely be better to wait for that release, as well as just to give more time for more of the blocker issues (
Blocker: New Stable
|
|
imo a solution that will end up with many people using a rc version connecting to the mp server for a long time is not a good idea (it seems to be ubuntus/debaisans policy not to update these packages). its still likely that it will still have severe bugs that we aren't aware of yet, and with those clients connecting to the mp server they would not only affect their own game experience but also negatively affect other players experience as well (especially for out of sync errors, but for random crashes its fuirstrating when the other player suddenly vanishes). The situation is already kinda bad with 1.16 where 1.16.2 is the second most common version, and we have fixed quite a few errors (including oos errors) since 1.16.2 |
|
Yeah, it's pretty inevitable that as soon as more people start using it there will be a bunch of new issues found as well. Ultimately the question is whether it's more important to get the new stable version (1.18) into the next LTS release even though it'll probably have some bugs vs staying on the less buggy (at least initially) 1.16 version that'll have basically no one on the multiplayer server a few months after 1.18 is released. |
Thanks, that's all good to know. Unfortunately, if we wait until 2024-02-18 at the earliest to upload a wesnoth-1.18 package to Debian's NEW queue (where all new packages get reviewed before installation into the Debian package archive's "unstable" branch), there's a very good chance the review won't be done before Ubuntu 24.04's Debian Import Freeze on 2024-02-29, since the review as I said can take anywhere around 2 days, 3 weeks, or 2 months. That would mean there won't be any 1.18 version in Ubuntu 24.04 at all, only 1.16.11. Is this better than Debian's development branches ("unstable" and "testing") briefly having a 1.18 Beta version in a package called "wesnoth-1.18"?
Yeah, I agree it's definitely far from ideal to have a fixed version with no updates through the life of an LTS release. But that happens because Ubuntu has only 122 people maintaining the 34,454 source packages (64,309 binary packages) currently in Ubuntu 24.04's unofficially maintained "universe" area where wesnoth is. This is not a problem in Debian, where the thousands of maintainers frequently upload newer versions of their packages to the backports branches. Debian's stable release always has the latest stable release of Wesnoth available and fully supported via backports. (Honestly, I don't understand why Ubuntu is so popular, knowing how the vast majority of it is practically unmaintained.) |
No, it's not an either-or. We can keep 1.16 available in Ubuntu 24.04 alongside 1.18. That's the advantage of having versioned and co-installable packages as we do. (The disadvantage being this NEW queue delay for each new stable branch of Wesnoth every couple years or so.) But I think the only way to have 1.18 (RC1) in Ubuntu 24.04 at all is by briefly having a Beta version (really 1.17, but we'll call the package "wesnoth-1.18") in the Debian "unstable" and "testing" branches, to get the NEW review started ahead of the RC1 release. And I won't backport 1.17 to the Debian "stable" branch; I'll wait and backport the final 1.18.0. |
|
I'm confused then - since Ubuntu won't update the package, wouldn't 24.04 be forever stuck at the RC1 release if that's used? Or have I been misunderstanding? |
|
That's correct, Ubuntu 24.04 will be stuck at 1.18 RC1 (but will also have 1.16.11, also stuck, as an alternative option to install). But Debian isn't stuck at the version it has on its release date; we backport newer versions of packages to stable-backports (e.g. Debian 12, released last June, already has Wesnoth 1.16.11 available and will eventually have 1.18.0). Does that answer your question? I'm sorry that this distribution sausage-making between Debian and Ubuntu is rather confusing, or I'm not explaining it clearly enough. |
|
Alright, that clears it up, thanks. Probably the safer option is to have just 1.16 for 24.04 then. We already have the occasional person asking why they have an older version of 1.16 anyway, to which our answer is "use Flatpak, Steam, or a different distro", so it'd just be more of the same there. It'll be easier to explain if there's just one old version vs one old version and another separate less old version though. |
|
That'll be a shame, in my opinion, to not have any 1.18 version available in Ubuntu 24.04, even for casual users who find and install it via Ubuntu Software Center or APT (instead of installing and learning a whole new package manager like Flatpak just to play a game) and who may not mind that it's not the latest stable version. And after I came up with this whole detailed plan (and got agreement from the lead maintainer in Debian and was just about to start working on it) to get 1.17.26 into Ubuntu in time for the Debian Import Freeze, heh. So given the options:
You prefer option 1? Keep in mind that as I said we will at least provide updates to Ubuntu 24.04 via our PPA. So a user might stumble upon the 1.17.26 package in Ubuntu proper and then be able to upgrade that exact package via the PPA easily enough, rather than having to install something like Flatpak (or worse, Steam) to play a game. As I said a week ago in #8170 for example, the PPA should solve the lack of updates from Ubuntu, so I suggest giving that answer (or recommending Debian as the "different distro" 😄). |
|
Honestly, I'm mostly ambivalent about it - if you want to make 1.17.26 available as 1.18-RC1, then I'm fine with that too. Even if it's somewhat buggy, it can't be any worse of a first impression to new players than the last 3+ years where installing from the package manager on Ubuntu only gives you the tutorial campaign available to play. |
|
OK, thanks, and sorry again for involving you in distribution packaging details. You say "make 1.17.26 available as 1.18-RC1", but to be clear, my plan is to name the package "wesnoth-1.18" (again, the package name and installed files/directories are versioned to allow users to choose to install either or both of a couple available versions) but leave all the version information as 1.17.26, not 1.18-RC1. Unless you disagree, I don't think that'll be too confusing for users; many probably won't even notice unless they dig a few screens into GNOME Software. Yeah, again I can't figure out what solution Rhonda had in mind for the campaigns packages issue, but I have an idea how to solve this (for both versions 1.16 and 1.18), and I'm asking her and Vincent whether they object or see an alternative solution. |
|
Alright, sounds good. And thanks for looking into the campaigns packages issue! |
|
I haven't read through this whole discussion, but I remember with considering the previous Ubuntu LTS that someone - Pent? - said something along the lines of Wesnoth as a project isn't subject to the arbitrary schedules of distribution releases. Even though it would be nice to accommodate a platform like Ubuntu given its relative popularity. |
Wedge009
added
the
Packaging
|
Yeah, the 1.17 roadmap says the same more or less:
If there was some big feature or set of features what would need until June 2024 (for example) to be ready, 1.18 would be coming out in June instead. So given there's not, might as well try to not leave the default Ubuntu package on 1.16. |
|
Given we're in March now (pretty sure that includes the western hemisphere as I write this), should this be closed? The cut-off date at the end of February has been and gone now. |
|
Makes sense to me. |
|
Ubuntu did go with 1.16.11 |
|
Well, so much for that then. |
Describe the desired feature
First, sorry, I know this is the wrong place for this. I think the right place would be the 1.17 roadmap discussion thread on the forums, but I'm not allowed to reply there. Suggestions welcome if I should post this somewhere else.
I see the 1.17 roadmap's "Instructions" section sets a deadline to release 1.18 "by February 2024" for inclusion in Ubuntu 24.04 LTS. But the end of the page shows a 1.18 release date of "03/17/2024". @Pentarctagon confirmed to me in a PR comment that "1.18 is planned to be released in March".
As you probably know, Wesnoth ends up in each Ubuntu release cycle via imports of the package maintained by the Debian Games Team from Debian unstable. The latest information I know is that Ubuntu 24.04 LTS (Noble Numbat) will enter the Debian Import Freeze stage (i.e. stop importing packages from Debian unstable) on February 29. And the wesnoth maintainer(s) in Debian will need a reasonable amount of lead time to upload a new version. For example, the latest stable version 1.16.11 was uploaded to Debian unstable in five days (a reasonably fast upload), and the lead maintainer reports an "overall lack of time recently". A significantly new version like 1.18 will likely take a little longer to package. (I'm on the Debian Games Team and can try to help update the package in time for Ubuntu noble, but I'm not a Debian Developer or Debian Maintainer, so another team member such as the package's lead maintainer would still need to do the actual upload to Debian unstable.) And as far as I know, no members of the Debian Games Team are Ubuntu Masters of the Universe (MOTUs, who maintain packages such as wesnoth in Ubuntu's unofficially maintained "universe" area); in fact our only way to provide updates for Ubuntu seems to be PPAs we maintain. So whatever version of wesnoth is in Ubuntu LTS at the Debian Import Freeze date will remain fixed through the lifetime of that Ubuntu LTS release (no backports are done of wesnoth or most other universe packages, because the MOTU team is quite small for the very large number of packages they maintain).
So overall, if the goal is still to get 1.18 into Ubuntu 24.04 LTS, I would recommend trying to release by early to mid February at the latest. Sorry if I'm either telling you things you already know or bearing bad news and asking for rushed development, and for not thinking to warn of this sooner.
The text was updated successfully, but these errors were encountered: