-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi everybody!
Now that I am close to starting a new stable series with Wesnoth I came across
a small problem with the way versions currently work in PXML. For this let me
explain a little first:
In Wesnoth we use two series in parallel. One is the stable series (currently
1.8.x), the other is the development series (currently 1.9.x). Eventually the
development series becomes the new stable series (in this case 1.9.x will
become 1.10.x). The main difference between those two versions is that the
stable series is significantly better for MP players due to having more
players on the server and it being a stable base for a while so that users can
adjust to balancing changes. The dev series on the other hand is often better
for people playing singleplayer in english and wanting all the latest bling.
So, now the problem:
How to approach the upgrade from 1.9.14 to 1.10.0? In theory this is a direct
upgrade. Though not only users of 1.9.x should update to 1.10.0 but also users
of 1.8.x. Basically there are two package ids at the moment which would both
become obsolete with the new series: wesnoth-1.8 as well as wesnoth-1.9. In
theory I could probably continue using the wesnoth-1.9 user data dir for 1.10
but would, because of this, also keep the package id. But how should 1.8.x
users be made aware of the update eg via the repo or package manager?
This is where my proposal comes into the picture:
What would be required here is some "recommended_upgrade" tag listing
(explicit) ids which should be replaced by this package. The tag would
probably be part of the <package> block and is because of this only relevant
for repositories and package managers. The syntax could look like this:
<package id="new_uniqueID">
(..)
<recommended_upgrades>
<package_id="old_uniqueID" />
<package_id="old_uniqueID2" />
</recommended_upgrades>
</package>
In this example the package "new_uniqueID" would recommend an update to it in
case either a package with "old_uniqueID" or "old_uniqueID2" is found. So
replacing several packages would be possible.
Use cases for this tag is what I listed above as well as cases where the old
maintainer of a package is completely gone and someone new is taking over eg
the development of an emulator.
In case a package is detected which asks to update other packages the
interface would somehow display that it can update the now outdated packages
and the user is to be asked if packages should be replaced with this new
package (so basically an optional upgrade path).
Implementation of this would not have to happen in libpnd itself but in eg the
repo as well as package managers. Open questions include how to best handle
appdata of the replaced packages. I don't have a nice solution for this
though. Here I'd simply go for "use the appdata the new application now provides".
Comments? Feedback? Am I missing anything important?
Cheers,
Nils Kneuper aka Ivanovic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk8YFz4ACgkQfFda9thizwUfuQCgmNKDLFqI4Hh69CABANqZ7/1E
d4AAoI2+9Ys8JqUF64u3LAdo1/uNIB1C
=JYS0
-----END PGP SIGNATURE-----