[wpkg-users] revision number problem
Rainer Meier
r.meier at wpkg.org
Fri Oct 2 19:29:45 CEST 2009
Hi Malte,
Malte Starostik wrote:
> When the revision number decreases, WPKG performs a downgrade.
This is entirely correct.
> For that to
> work, you need to add <downgrade cmd="..."/> actions to your package.
This is true as well. The downgrade command has been introduced not so long ago.
I recommend using the latest WPKG 1.1.2 revision.
> But as
> this isn't really a downgrade, I'd recommend to use the real version numbers
> as revisions. Sth. like "3.5.1.1" => "3.5.3" will be correctly interpreted as
> an upgrade while "3511" => "353" will not.
This is true as well and has been introduced quite recently by a heavy
improvement of the version comparison algorithm.
WPKG starts comparing the number values from the left side. So comparing
3511 to 353 => downgrade
3511 to 353.0 => downgrade
3511.0 to 353.0 => downgrade
3.511 to 3.5.3 => downgrade
3.5.1.1 to 3.5.3 => upgrade
3.5.1.1 to 3.5.1.2 => upgrade
So make sure not mixing your numbering schemes. Old versions of WPKG only
supported integer values in the revision attribute. This enforced you to use
versions like "3511". If you're intending to move to a "dotted" version number
scheme you can of course. For example using "3511" currently and then updating
the package to read "3.5.3" is valid - but you need to specify a downgrade
command (which of course can do a simple Firefox installation, exactly like the
upgrade).
For quite a lot of applications a downgrade can be performed with the same
commands as an upgrade. However in this case it's just WPKG thinking it makes a
downgrade while it actually performs upgrade commands. Just make sure your
checks match the correct state after upgrade/downgrade.
br,
Rainer
More information about the wpkg-users
mailing list