Hash: SHA1

Philipp von Weitershausen wrote:
> On 26 Sep 2007, at 22:34 , Benji York wrote:
>> Philipp von Weitershausen wrote:
>>> Stephan Richter wrote:
>>>> Because I disagree with that, since you cannot know the next  
>>>> version.
>>> You can always know the minimum version. If you just released  
>>> 3.4.2, I think it's sensible to point the next release to 3.4.3.  
>>> If you later decide that you really need a feature release, you  
>>> can always bump to 3.5.0a1 (which would be the first release in  
>>> the 3.5.x series).
>> Why not leave the version totally out of the setup.py in the trunk?  
>> After branching for a release we can set the version (e.g., 1.2),  
>> make a release, and tag the branch.
>> We could either leave the version on the branch at the "last"  
>> release or continue the trend of mad bumping and have it at the  
>> "next" release (which since this is a branch, we can actually  
>> predict).
>> I prefer the "last" version, but "next" would work too.
> setuptools suggests setting it to the "next" version. Apart from the  
> fact that it makes more sense to me, the biggest reason I can see is  
> the development egg use case. A development egg from the repository  
> should have a newer version than the latest released egg.

If it were impossible to create an 'sdist' or 'bdist_egg' from such a
checkout, I would be OK with this.  However, history shows that people
*will* make distributions from such "not-ready-for-prime-time"
checkouts, at which point the damage is orders of magnitude bigger than
any value derived from convenience in installing the 'develop' egg.

- --
Tres Seaver          +1 540-429-0999          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

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

Reply via email to