Re: [ ACTION-107] Updating version list identifier algorithm

On 9/19/07, Ian Hickson <ian@hixie.ch> wrote:
> On Tue, 18 Sep 2007, Marcos Caceres wrote:
>
> One would expect far more software to have reached the initial 1.01/1.1
> stage than the 1.10 stage. Yet, if you do a search for "version 1.10",
> you'll find almost as many as for "version 1.01". This indicates, in my
> opinion, that the list-of-integers based numbering is more common than the
> decimal number system.
>
> Using floats means that
>
>    1.10.0
>
> ...counts as lower than:
>
>    1.2.0
>
> ...which is clearly not correct either.

Nice show-stopper! Let me think about it some more.

> In any case, I would recommend not parsing versons at all. Just treat them
> as opaque strings, and assume that there is an upgrade if the version on
> the server doesn't match the version in the client.

I could live with this, but it still makes me uncomfortable. What
happens if I accidentally override a new version with an old version
by mistake and don't realize it for a few days?... or, I've uploaded a
new version and lots of people download it, then a hard disk on my
server crashes and the ISP auto-recovers an old version, and then all
my users start re-downloading the old version? Obviously, I don't want
that to happen.

> If you do parse the version numbers, then you run into the problem that if
> someone accidentally pushes a really high version number like
> version="110" instead of "1.1.0", then they are forever forced to have
> their version be higher than that so that everyone can upgrade. It also
> means that if a serious regression is found in a new widget version,
> authors can't just immediately downgrade, they have to go and repackage
> the widget with a new version number and then push that.

Understood. However, I think that would rarely happen (though I cannot
prove it). Even in the case of a screw-up like the one you mentioned,
the repackaging is simple: just change the version element or
attribute to a greater version and re-zip (eg. 111) and apologize
profusely for the mistake within a <description> element:)

Before we get too much more into this, I think I need to put together
a complete model for automatic updates that is inclusive of HTTP
caching and can somehow retain the relevant caching data when files
being copied from one device to another (over BlueTooth or whatever).
I started editing something a few weeks ago [1], but have not yet had
a chance to update it to reflect what has been discussed in this
thread.

Kind regards,
Marcos

[1] http://dev.w3.org/2006/waf/auto-updates/Overview.src.html

-- 
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 19 September 2007 01:52:38 UTC