On Sat, Nov 28, 2009 at 10:05 PM, P.J. Eby p...@telecommunity.com wrote:
At 09:41 AM 11/28/2009 +0100, Tarek Ziadé wrote:
That's completely wrong, the proposal is a benefit for all of us,
because it standardizes something that is already being done.
You seem to have misunderstood me; I'm
P.J. Eby p...@telecommunity.com writes:
At 12:26 PM 11/28/2009 +1100, Ben Finney wrote:
My understanding of PEP 386 is that it *isn't* about asking Python
developers to change how they work. Is that not right?
Asking them to generate alternative versioning schemes, without the
ability to
On Sat, Nov 28, 2009 at 12:32 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
[..]
the problem we have is to be able to sort those post and pre releases
with other versions. And this is not possible with a simple
alphanumerical comparison.
It is, if the version strings are chosen to fit
On Sat, Nov 28, 2009 at 2:02 AM, P.J. Eby p...@telecommunity.com wrote:
At 10:32 AM 11/28/2009 +1100, Ben Finney wrote:
This is a red herring, AFAICT. It's been discussed already that workflow
is orthogonal to version comparison semantics. That is, nothing about a
workflow involving snapshots
On Sat, Nov 28, 2009 at 2:26 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
[..]
Why should developers change, and packagers not?
Packagers *do* change how they work; Piotr has been explaining at length
how packagers put in efforts to meet version-comparison semantics half
way. I'm asking
On Sat, Nov 28, 2009 at 4:00 AM, P.J. Eby p...@telecommunity.com wrote:
At 12:26 PM 11/28/2009 +1100, Ben Finney wrote:
I think you're reading a proposal that I didn't write.
Are you not the person who's proposed using simple alphanumeric strings for
version comparison?
My understanding of
In a message of Sat, 28 Nov 2009 10:27:14 +0100, Tarek Ziadé writes:
On Sat, Nov 28, 2009 at 7:31 AM, Laura Creighton l...@openend.se wrote:
It occurs to me that this problem would go away if we had a way to
ask, for any given version number, 'what was your creation date' and
the sorting
Ben Finney wrote:
Eric Smith e...@trueblade.com writes:
Ben Finney wrote:
Since the specification is about version *comparison* semantics, I'd
need to know example version strings that should compare “prior” and
“subsequent” for the version string I'm to propose. Can you give
examples?
I
On Fri, Nov 27, 2009 at 10:00:22PM -0500, P.J. Eby wrote:
This is why I've argued for keeping a scheme in 386 that can
mechanically translate most existing versioning schemes found in the
wild: it means that most people won't have to do a thing, as tool
builders can just use suggest_version().
Eric Smith e...@trueblade.com writes:
Ben Finney wrote:
That is, you want me to propose an example version string X. I'm
asking for you to tell me corresponding examples of version strings
W and Y where:
W X Y
since the comparison semantics are what we're discussing here.
On Sat, Nov 28, 2009 at 9:22 PM, Laura Creighton l...@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
On Nov 28, 2009, at 4:50 AM, Laura Creighton wrote:
At some point, we all agree that MAJOR.MINOR.MICRO is an accepted
standard and we are arguing about pre/post/dev releases.
We have no way to enforce this on the world. The arguments here may
have gone away, but out in the wild, I think we
On Sat, Nov 28, 2009 at 1:52 PM, Laura Creighton l...@openend.se wrote:
[...]
Yes, this is why I am coming to the conclusion that we are asking
too much of a versioning scheme.
Thus I think we need, instead, a way to specify two things.
First of all Requires-Dist: needs to be able to
On Sat, Nov 28, 2009 at 12:28 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
On Fri, Nov 27, 2009 at 10:00:22PM -0500, P.J. Eby wrote:
This is why I've argued for keeping a scheme in 386 that can
mechanically translate most existing versioning schemes found in the
wild: it means that
On Sat, Nov 28, 2009 at 05:07:01PM +0100, Tarek Ziadé wrote:
So If the current proposal works for all cases (e.g. people can
translate their schemes
into PEP 386 one), I am proposing to:
1- reject the +, , - proposal, and stick with . so we have
only one way to express the segments. (ala
On Sat, Nov 28, 2009 at 05:07:01PM +0100, Tarek Ziadé wrote:
On Sat, Nov 28, 2009 at 12:28 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
This is an important point. I tought the aim of PEP 386 was to create
a version scheme that can represent every version number developers
At 10:50 AM 11/28/2009 +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.
You're assuming a process with no branches, where e.g. version 1.2 is
being
At 09:41 AM 11/28/2009 +0100, Tarek Ziadé wrote:
That's completely wrong, the proposal is a benefit for all of us,
because it standardizes something that is already being done.
You seem to have misunderstood me; I'm objecting to Ben Finney's
simple alphanumeric sort, not to PEP 386 in
Tarek Ziadé ziade.ta...@gmail.com writes:
3 - stick with post dev for the post and pre-release tags because
*we need them to sort development versions and post versions* in
installers, and because *they don't hurt* for people that are not
publishing such versions.
I disagree on both counts —
Ben Finney schrieb:
Eric Smith e...@trueblade.com writes:
Ben Finney wrote:
That is, you want me to propose an example version string X. I'm
asking for you to tell me corresponding examples of version strings
W and Y where:
W X Y
since the comparison semantics are what
On Sat, Nov 28, 2009 at 10:53 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Tarek Ziadé ziade.ta...@gmail.com writes:
3 - stick with post dev for the post and pre-release tags because
*we need them to sort development versions and post versions* in
installers, and because *they don't hurt*
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Laura Creighton wrote:
It occurs to me that this problem would go away if we had a way to
ask, for any given version number, 'what was your creation date' and
the sorting 'earlier' and 'later' by that date. Can somebody explain
why we aren't
Tarek Ziadé ziade.ta...@gmail.com writes:
That makes me think that a nice add-on to the lib and the PEP would be
to provide APIs to translate a Python PEP 386 version to a
Debian/Ubuntu or RPM ones - and any major packaging system out there.
(whatever scheme we pick)
I'd like to register,
Tarek Ziadé ziade.ta...@gmail.com writes:
On Fri, Nov 27, 2009 at 1:52 PM, Ben Finney ben+pyt...@benfinney.id.au
wrote:
I'd like to register, once again, the point that [translating PEP
386 version comparison semantics to existing semantics] would not
*be* a problem if PEP 386 described
Ben Finney wrote:
Yes, and others that have been proposed to be exceptions to alphanumeric
ordering.
the problem we have is to be able to sort those post and pre releases
with other versions. And this is not possible with a simple
alphanumerical comparison.
It is, if the version strings are
Eric Smith e...@trueblade.com writes:
Ben Finney wrote:
the problem we have is to be able to sort those post and pre
releases with other versions. And this is not possible with a
simple alphanumerical comparison.
It is, if the version strings are chosen to fit within such a
At 10:32 AM 11/28/2009 +1100, Ben Finney wrote:
This is a red herring, AFAICT. It's been discussed already that
workflow is orthogonal to version comparison semantics. That is,
nothing about a workflow involving snapshots or dev versions etc.
implies that exceptional version keywords need to
P.J. Eby p...@telecommunity.com writes:
At 10:32 AM 11/28/2009 +1100, Ben Finney wrote:
Moreover, AIUI there is no injunction that all projects must follow
exactly the semantics of PEP 386, right? So why not have a *simple*
standard (all version string components compared alphanumerically)
Ben Finney wrote:
Eric Smith e...@trueblade.com writes:
Ben Finney wrote:
the problem we have is to be able to sort those post and pre
releases with other versions. And this is not possible with a
simple alphanumerical comparison.
It is, if the version strings are chosen to fit within such a
At 12:26 PM 11/28/2009 +1100, Ben Finney wrote:
I think you're reading a proposal that I didn't write.
Are you not the person who's proposed using simple alphanumeric
strings for version comparison?
My understanding of PEP 386 is that it *isn't* about asking Python
developers to change how
It occurs to me that this problem would go away if we had a way to
ask, for any given version number, 'what was your creation date' and
the sorting 'earlier' and 'later' by that date. Can somebody explain
why we aren't doing this?
Laura
___
Eric Smith e...@trueblade.com writes:
Ben Finney wrote:
Since the specification is about version *comparison* semantics, I'd
need to know example version strings that should compare “prior” and
“subsequent” for the version string I'm to propose. Can you give
examples?
I want to install
33 matches
Mail list logo
