On Thu, Dec 3, 2009 at 5:19 PM, M.-A. Lemburg m...@egenix.com wrote:
[..]
A snapshot will always be a version of a pre-release, so
it's clear that you get a snapshot when looking at:
1.0.0a0.123
(the a0 signals the pre-release status)
OTOH, versions without pre-release marker are
Tarek Ziadé wrote:
Last, as I said in a previous mail, I tend to agree with the people
who said that we should stick with only one way to write the version
scheme for the sake of clarity. e.g. dropping aliases and picking
*one* way to write the markers after major.minor.micro.
I would tend
On Thu, Dec 03, 2009 at 01:55:53PM +0100, M.-A. Lemburg wrote:
Tarek Ziadé wrote:
Last, as I said in a previous mail, I tend to agree with the people
who said that we should stick with only one way to write the version
scheme for the sake of clarity. e.g. dropping aliases and picking
On Thu, Dec 3, 2009 at 1:55 PM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
Last, as I said in a previous mail, I tend to agree with the people
who said that we should stick with only one way to write the version
scheme for the sake of clarity. e.g. dropping aliases and picking
Tarek Ziadé wrote:
On Thu, Dec 3, 2009 at 1:55 PM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
Last, as I said in a previous mail, I tend to agree with the people
who said that we should stick with only one way to write the version
scheme for the sake of clarity. e.g. dropping
Toshio Kuratomi wrote:
On Thu, Dec 03, 2009 at 01:55:53PM +0100, M.-A. Lemburg wrote:
Tarek Ziadé wrote:
Last, as I said in a previous mail, I tend to agree with the people
who said that we should stick with only one way to write the version
scheme for the sake of clarity. e.g. dropping
[..]
1. whether it's release quality code
1.0.0
2. whether it's a development snapshot
1.0.0a0.20091202
3. whether it's working code, but still under development
1.0.0a1
4. whether it fixes some bug that was found after a release
1.0.1
How do you
Tarek Ziadé wrote:
[..]
1. whether it's release quality code
1.0.0
2. whether it's a development snapshot
1.0.0a0.20091202
3. whether it's working code, but still under development
1.0.0a1
4. whether it fixes some bug that was found after a release
1.0.1
On Thu, Dec 03, 2009 at 04:50:50PM +0100, M.-A. Lemburg wrote:
The dev markers introduce an extra level of confusion, which
IMHO is not necessary.
Let's take 1.0a0.dev123 as example, reading it from the left:
1.0 - ok, so this is part of a 1.0 release
1.0a0- oops, no,
P.J. Eby wrote:
At 09:15 PM 11/29/2009 +0100, Tarek Ziadé wrote:
2009/11/29 P.J. Eby p...@telecommunity.com:
[..]
WSGI and setuptools have been widely adopted in spite of their
technical and
ideological flaws, because they had good incentive engineering.
Or, in other words, because
On Mon, Nov 30, 2009 at 10:49:55AM +0100, M.-A. Lemburg wrote:
so I don't see much of a problem with breaking
forward compatibility in this case.
Indeed, but equally so I don't see an advantage in breaking forward
compatibility in this case (i.e. underscores in PEP 386 don't allow us
to express
P.J. Eby wrote:
At 08:11 PM 11/28/2009 +0100, M.-A. Lemburg wrote:
Tarek Ziadé wrote:
On Thu, Nov 26, 2009 at 1:08 PM, M.-A. Lemburg m...@egenix.com wrote:
Here's another take at a minimal change to the format which
includes the things we discussed, adds a few more aliases
for the post
2009/11/29 M.-A. Lemburg m...@egenix.com:
[..]
Please don't add underscores to the syntax -- they will cause problems
with the filename escaping and parsing used today by setuptools and
compatible tools, and will produce inconsistent comparisons between
rational versions and the version
2009/11/29 P.J. Eby p...@telecommunity.com:
[..]
WSGI and setuptools have been widely adopted in spite of their technical and
ideological flaws, because they had good incentive engineering.
Or, in other words, because practicality beats purity, every single time.
Do you mean here that this
At 09:15 PM 11/29/2009 +0100, Tarek Ziadé wrote:
2009/11/29 P.J. Eby p...@telecommunity.com:
[..]
WSGI and setuptools have been widely adopted in spite of their
technical and
ideological flaws, because they had good incentive engineering.
Or, in other words, because practicality beats
On Fri, Nov 27, 2009 at 8:55 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
[lots of explanation]
Thanks for these explanations Toshio. I am starting to think that
whatever we use on Python side will be fine for you guys, (and for
Ubuntu/Fedora guys), as long as it is
described in the PEP.
So I
Tarek Ziadé wrote:
On Thu, Nov 26, 2009 at 1:08 PM, M.-A. Lemburg m...@egenix.com wrote:
Here's another take at a minimal change to the format which
includes the things we discussed, adds a few more aliases
for the post and dev markers and also adds optional
underscores for more readability.
At 08:11 PM 11/28/2009 +0100, M.-A. Lemburg wrote:
Tarek Ziadé wrote:
On Thu, Nov 26, 2009 at 1:08 PM, M.-A. Lemburg m...@egenix.com wrote:
Here's another take at a minimal change to the format which
includes the things we discussed, adds a few more aliases
for the post and dev markers and
[Tarek Ziadé, 2009-11-26]
On Thu, Nov 26, 2009 at 8:55 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
[..]
since the .dev versions are really only snapshots leading up to
some release, i.e. 1.0.dev456 is a snapshot leading up to the
first pre-release of the 1.0 :-)
But in
On Fri, Nov 27, 2009 at 11:39 AM, Piotr Ozarowski oza...@gmail.com wrote:
[Tarek Ziadé, 2009-11-26]
On Thu, Nov 26, 2009 at 8:55 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
[..]
since the .dev versions are really only snapshots leading up to
some release, i.e. 1.0.dev456 is a
On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
[..]
don't worry about Debian, we'll simply replace - with ~ (we use ~
and + right now[0]). I'm not sure about rpm, but I bet it has
something similar and it will be much easier for us to simply handle two
characters
[Tarek Ziadé, 2009-11-27]
On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
[..]
don't worry about Debian, we'll simply replace - with ~ (we use ~
and + right now[0]). I'm not sure about rpm, but I bet it has
something similar and it will be much easier for us to
On Nov 27, 2009, at 7:31 AM, Tarek Ziadé wrote:
On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
[..]
don't worry about Debian, we'll simply replace - with ~ (we use ~
and + right now[0]). I'm not sure about rpm, but I bet it has
something similar and it will be
On Fri, Nov 27, 2009 at 3:31 PM, sstein...@gmail.com
sstein...@gmail.com wrote:
On Nov 27, 2009, at 7:31 AM, Tarek Ziadé wrote:
On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
[..]
don't worry about Debian, we'll simply replace - with ~ (we use ~
and + right
[sstein...@gmail.com, 2009-11-27]
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)
Wouldn't it be cool if the
On Nov 27, 2009, at 9:41 AM, Tarek Ziadé wrote:
I'm still very interested in the increment_version functionality we talked
about earlier so that we could have our build process automatically up our
release version numbers so we have a standard way of maintaining incremental
versioning.
On Nov 27, 2009, at 9:58 AM, Piotr Ozarowski wrote:
[sstein...@gmail.com, 2009-11-27]
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.
Here's another take at a minimal change to the format which
includes the things we discussed, adds a few more aliases
for the post and dev markers and also adds optional
underscores for more readability.
VERSION_RE = re.compile(r'''
^
(?Pversion\d+\.\d+) # minimum 'N.N'
On Thu, Nov 26, 2009 at 01:08:34PM +0100, M.-A. Lemburg wrote:
Examples:
3.2.0a0.20091125
3.2.0a1
= 3.2.0_alpha_1
Frankly I find this confusing. I'm fine with 'alpha' being a synonym
for 'a' but the underscores just confuse things IMHO.
3.2.0a1.20091125
3.2.0rc1
= 3.2.0c1
2009/11/26 Tarek Ziadé ziade.ta...@gmail.com:
I am +1 for keeping the intuitive writing for the pre-release cycle.
s/for the pre-release cycle./before the pre-release cycle starts/
___
Distutils-SIG maillist - Distutils-SIG@python.org
At 07:55 PM 11/26/2009 +, Floris Bruynooghe wrote:
On Thu, Nov 26, 2009 at 01:08:34PM +0100, M.-A. Lemburg wrote:
Examples:
3.2.0a0.20091125
3.2.0a1
= 3.2.0_alpha_1
Frankly I find this confusing. I'm fine with 'alpha' being a synonym
for 'a' but the underscores just confuse things
Could we extend the pseudo-format of the versions a little to also
include variants which use more than just one character and also
allow hyphens and spaces to be used for additional clarity ?
VERSION_RE = re.compile(r'''
^
(?Pversion\d+\.\d+) # minimum 'N.N'
M.-A. Lemburg wrote:
Could we extend the pseudo-format of the versions a little to also
include variants which use more than just one character and also
allow hyphens and spaces to be used for additional clarity ?
VERSION_RE = re.compile(r'''
^
(?Pversion\d+\.\d+) #
2009/11/25 M.-A. Lemburg m...@egenix.com:
M.-A. Lemburg wrote:
Could we extend the pseudo-format of the versions a little to also
include variants which use more than just one character and also
allow hyphens and spaces to be used for additional clarity ?
VERSION_RE = re.compile(r'''
^
On Nov 25, 2009, at 12:44 PM, M.-A. Lemburg wrote:
M.-A. Lemburg wrote:
Could we extend the pseudo-format of the versions a little to also
include variants which use more than just one character and also
allow hyphens and spaces to be used for additional clarity ?
VERSION_RE =
Tarek Ziadé wrote:
2009/11/25 M.-A. Lemburg m...@egenix.com:
M.-A. Lemburg wrote:
Could we extend the pseudo-format of the versions a little to also
include variants which use more than just one character and also
allow hyphens and spaces to be used for additional clarity ?
VERSION_RE =
sstein...@gmail.com wrote:
While I like the use of rc for release candidate, doesn't this lead to some
ambiguity where a,b,c are seen as interim releases with rc sorting after
all of these?
I don't have an objection to [a-q] OR 'rc' if we're reserving rc for
release candidate and only rc
On Wed, Nov 25, 2009 at 9:04 PM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
2009/11/25 M.-A. Lemburg m...@egenix.com:
M.-A. Lemburg wrote:
Could we extend the pseudo-format of the versions a little to also
include variants which use more than just one character and also
allow
Tarek Ziadé wrote:
On Wed, Nov 25, 2009 at 9:04 PM, M.-A. Lemburg m...@egenix.com wrote:
I was under the impression that developers should be encouraged
to use the new rational version format directly in their
package versions - without a helper in between.
Yes that's the idea. I was just
On Wed, Nov 25, 2009 at 9:52 PM, M.-A. Lemburg m...@egenix.com wrote:
[..]
If we'd allow [a-z_] (including the underscore which AFAIK doesn't
cause RPM/deb problems), this could also be written as:
3.2.0_dev_snapshot.20091125
... much better :-)
How do you sort them in that case ?
On Wed, Nov 25, 2009 at 09:52:45PM +0100, M.-A. Lemburg wrote:
BTW: How would you name a snapshot using the scheme ?
Say you are working on an upcoming version 3.2.0 of a package and you
use the date as snapshot indicator (as opposed to some revision, which
doesn't have any meaning for an
Tarek Ziadé wrote:
On Wed, Nov 25, 2009 at 9:52 PM, M.-A. Lemburg m...@egenix.com wrote:
[..]
If we'd allow [a-z_] (including the underscore which AFAIK doesn't
cause RPM/deb problems), this could also be written as:
3.2.0_dev_snapshot.20091125
... much better :-)
How do you sort
Hello,
PEP 386 seem to be ready, and I would like to push if for feedback at
python-dev, just before PEP 345 is pushed.
My only concern is now to make sure the PEP motivations and
explanations are crystal clear.
Anyone see any problem ? or have any concern with this PEP ?
This PEP is the basis
Hi Tarek,
Tarek Ziadé wrote:
Anyone see any problem ? or have any concern with this PEP ?
Just a question: will it affect how version are checked for tools (e.g.
get_versions in distutils/cygwinccompiler.py) ?
cheers,
David
___
Distutils-SIG
On Tue, Nov 24, 2009 at 10:50 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Hi Tarek,
Tarek Ziadé wrote:
Anyone see any problem ? or have any concern with this PEP ?
Just a question: will it affect how version are checked for tools (e.g.
get_versions in
On Nov 24, 2009, at 4:47 AM, Tarek Ziadé wrote:
Hello,
PEP 386 seem to be ready, and I would like to push if for feedback at
python-dev, just before PEP 345 is pushed.
My only concern is now to make sure the PEP motivations and explanations are
crystal clear.
Anyone see any problem ?
On Tue, Nov 24, 2009 at 2:31 PM, sstein...@gmail.com
sstein...@gmail.com wrote:
[..]
There are, however, some issues that should be addressed before it's accepted
as final.
1 There seems to be a typo on line 29 of verlib.py where it says 'f'
'b', shouldn't that be 'b' 'f' ?
Right,
On Nov 24, 2009, at 3:40 PM, Tarek Ziadé wrote:
2 The explanation for suggest_rational_version is stubbed out in the
README.txt file:
XXX explain here suggest_rational_version
it should be documented what we expect it to do and that leads into...
This
48 matches
Mail list logo
