Re: [Zope3-dev] Release process closure
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
Re: [Zope3-dev] Release process closure
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
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
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. 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
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. 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
