Activity versioning schema

Eben Eliason eben.eliason at gmail.com
Mon Jul 14 18:48:43 EDT 2008


On Mon, Jul 14, 2008 at 6:41 PM, C. Scott Ananian <cscott at laptop.org> wrote:

> On Mon, Jul 14, 2008 at 6:24 PM, Eben Eliason <eben.eliason at gmail.com>
> wrote:
> > I think this is still a whole bunch clearer than trying to convince
> someone
> > that version 5 is newer than version 10! (where 10 is a "bugfix" release
> to
> > what used to be version 4.)
>
> You're undercutting your own points: what does "newer" mean?  If you
> want chronological "newness", then use ISO8601 dates.  Otherwise, just
> release a version 11 at the same time as 10, so that versions 10 and
> 11 are the chronologically newest releases, 11 for 8.2 users and 10
> for 8.1 users, and those people using '9' don't get confused.  This


This isn't always possible.  If I release version 10 (because it takes
advantage of some new feature in a new OS) and then later find out I have a
critical bug in an older version of the OS that still has a wide support
window, I'm forced to release 11 after 10, even though its an older code
base.  I'm not concerned at all with temporal newness, or this would be a
non-issue.


>
> really seems like a non-issue to me.  If your development style really
> wants to use minor versions, make up your own mapping to integers: 5.0
> = 500, 5.1=501, etc.  But regardless, adding dotted integers for
> version numbers isn't a real concern for me: it touches a number of
> pieces of code and documentation at this point, but we can go ahead
> and make that change early in 9.1 if you like.  But it still doesn't
> actually do anything towards solving the problem you initially posed:
> the only difference between 500 and 5.0 is perceptual.


I read on our wiki that the version number was supposed to be monotonically
increasing.  If that were the case, doing as you suggest isn't valid, as I
would never be able to release anything with a version below 500 once I had,
defeating the purpose.  Also, the current page on activity bundles
explicitly states that "Larger versions are considered 'newer'", which is
simply not the case, even if we do allow your scheme proposed above, which,
I agree, is technically equivalent.

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080714/93d41c2b/attachment.html>


More information about the Devel mailing list