On Sat, Nov 28, 2009 at 9:22 PM, Laura Creighton <[email protected]> wrote: > In a message of Sat, 28 Nov 2009 11:01:45 GMT, Floris Bruynooghe writes: >>On Sat, Nov 28, 2009 at 10:50:36AM +0100, Laura Creighton wrote: >>> But I think that it is the other way around ... what we want is a >>> timestamp. The algorithm is for guessing which version is ealier >>> in the absence of a timestamp. >> >>Does this work when you have a two maintenance branches releasing in >>parallel? Consider this example: >> >>2009-01-01: 1.0 >>2009-02-01: 1.1 >>2009-02-20: 1.0.1 (1.0 maint branch) >>2009-02-21: 1.1.1 (1.1 maint branch) >> >> >>Regards >>Floris > > Not if the only thing you sort on is the date -- which by the way should > have hours and minutes as well -- because, as you say that is not enough > to tell the 1.1 branch from the 1.0 branch. But once you have a name for > a series of releases, then a timestamp can sort the series. > > Let us say that you now find a horrible bug and make: > > 2009-02-22-22:01: 1.0.2 > 2009-02-22-22:04: 1.1.2 > > Now I want to say 'requires this bugfix'. Right now I think that if > I say requires 1.0.2 or later, then people with 1.1 will expect that > they are ok, when they are not. Or am I misunderstanding?
This is a slippery road. You will always find cases where any version scheme will fail if you start caring about those issues through version schemes only. In your example, that would be if different micro releases are not synchronized, which happens quite often in my experience. cheers, David _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
