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 |