[Zope3-dev] Release process closure

2007-10-03 Thread Jim Fulton


I'd really like to get to closure on the current approved release  
process. Philipp, would you mind separating the release process into  
a separate file?  Or do you mind if I do it?


Some comments on the current draft at:

  http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/ 
maintaining-software.txt


WRT version numbers in setup.py.  I'm inclined to endorse Philipp's  
recommendation for now.  If there was a way to specify a version  
number on the command line (or in a buildout.cfg) when creating  
develop eggs, then I'd have a different position, but given current  
technology, I think Philipp's recommendation, as I understand it, is  
best.


I think there are some details missing.  I think the intend is that  
the version number in the setup.py on the trunk and on release  
branches should have the dev suffix.  I think this is good as a  
reminder and a flag that accidentilly released dev eggs are suspect.


I think the dance should be that, to make a release, you make a tag  
and then edit the version number on the tag.  I think this sort of  
editing on a tag is reasonable and it is fortuitous that svn allows it.


Also, by default, the next version on the trunk should be a release  
with the second number incremented.  The next version on a release  
branch should have the 3rd number incremented. This is a minor  
detail, especially since I think we can avoid release branches for  
most projects and I think that release branches shouldn't be created  
until they are needed.  Of course, tags should always be created.


There are other improvements that might be made, but let's not let  
the perfect be the enemy of the good.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Release process closure

2007-10-03 Thread Benji York

Jim Fulton wrote:
I'd really like to get to closure on the current approved release  
process.


+1

There are other improvements that might be made, but let's not let  
the perfect be the enemy of the good.


This isn't perfect, so I get to suggest it. wink

I propose that we codify the practice of release tags having their x.y.z 
version number as their name, and in the setup.py.

--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Release process closure

2007-10-03 Thread Jim Fulton


On Oct 3, 2007, at 11:12 AM, Benji York wrote:


Jim Fulton wrote:
I'd really like to get to closure on the current approved release   
process.


+1

There are other improvements that might be made, but let's not  
let  the perfect be the enemy of the good.


This isn't perfect, so I get to suggest it. wink

I propose that we codify the practice of release tags having their  
x.y.z version number as their name, and in the setup.py.


Which implies that we codify 3-number version numbers, that is:

  major.minor.bugfix

with optional modifiers of the form dev, aN, bN, or cN.

I also suggest a special version numbering scheme when we package  
something else.  For example, if we package Twisted ro package some  
external js library in a Python package.  In this case, I suggest  
we   use the version number of the thing being packages with the  
addition of a post-release addition.  For example, a packaging of  
MochiKit 1.3.1 might have a version # like 1.3.1-1, or, if it is  
exciting enough: 1.3.1-1.1


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Release process closure

2007-10-03 Thread Benji York

Jim Fulton wrote:
For example, a packaging of  
MochiKit 1.3.1 might have a version # like 1.3.1-1, or, if it is  
exciting enough: 1.3.1-1.1


I assume setuptools interprets version numbers like this in a reasonable 
way.

--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Release process closure

2007-10-03 Thread Jim Fulton


On Oct 3, 2007, at 11:46 AM, Benji York wrote:


Jim Fulton wrote:
For example, a packaging of  MochiKit 1.3.1 might have a version #  
like 1.3.1-1, or, if it is  exciting enough: 1.3.1-1.1


I assume setuptools interprets version numbers like this in a  
reasonable way.


AFAIK. :)

Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Release process closure

2007-10-03 Thread Baiju M

Jim Fulton wrote:


 I'd really like to get to closure on the current approved release
 process. Philipp, would you mind separating the release process into
 a separate file?  Or do you mind if I do it?

 Some comments on the current draft at:



http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt



 WRT version numbers in setup.py.  I'm inclined to endorse Philipp's
 recommendation for now.  If there was a way to specify a version
 number on the command line (or in a buildout.cfg) when creating
 develop eggs, then I'd have a different position, but given current
 technology, I think Philipp's recommendation, as I understand it, is
 best.


+1

Regards,
Baiju M

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com