Re: [Distutils] Common version-comparison semantics for peace love and harmony

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? Laura

On Sat, Nov 28, 2009 at 9:22 PM, Laura Creighton <lac@openend.se> 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

Laura Creighton wrote:
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?
In cases like that, I don't think any scheme that relies on comparing with a single version number will be sufficient. You really need to specify a more complex requirement, such as 1.0.2 <= x < 1.1 or x >= 1.1.2 Even if you have a notion of grouping releases into series, it can still get complicated. E.g. suppose the bug was only fixed in the 1.1.3 release of the 1.1 branch -- then you need to compare with different micro release numbers in each branch. -- Greg
participants (3)
-
David Cournapeau
-
Greg Ewing
-
Laura Creighton