-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: > On 26 Sep 2007, at 23:18 , Jim Fulton wrote: >> On Sep 26, 2007, at 4:34 PM, 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). >> Gary and Benji made me pay attention to this point. :) >> >> I *really* don't like setting the version to the number for the >> next release, since one often doesn't know what it is. > > Maybe. However, when you do the actual release then, you're still > going to have to find out which version number to use. On release > branches this is a trivial step, of course: You just look at the > latest tagged version and increment accordingly. On the trunk it > might be trickier. After 1.0, do we have 1.1? Or 2.0? > > Maye this aspect isn't such a big deal, though. > >>> Why not leave the version totally out of the setup.py in the trunk? >> Benji and Gary won me over to this point of view. :) > > There's a *really* good reason for putting the upcoming version > number in setup.py, though: development eggs.
- -100. 'development eggs' which get released into the wild are an abomination of desolation, and should be avoided at *any* cost. (I'm assuming that you mean eggs / distributions which get uploaded to some package repository, rather than being installed via 'setup.py develop'). > Let's say X depends on Y and I'm developing them simultaneously as > development eggs in one sandbox (e.g. buildout). I add a feature to Y > that I'd like to use in X. That means I'll have to change X's version > dependency regarding Y so that it now depends on Y>a.b where a.b is > the latest release that didn't have the feature I added. Logically speaking, you *can't* release Y with the new requirement until *after* a release of X is availabe with the required feature: while they are both in development, hacking on Y's 'install_requires' is pointless. Once X is released with the new feature, *then* you can update the develpoment egg for 'Y' to mandate that version of 'X': at that point, you should be removing the development egg of 'X', in order to verify that 'Y' works with an installable 'X'. > Will Y with the setup.py stating version='unreleased' satisfy the > Y>a.b requirement that X (rightfully) has? If not, then I think we > have a problem. If yes, then I find that very confusing. 'Y' can't be changed simultaneously with 'X': that is the nature of dependency management. > I know that if Y's setup.py stated version='a.b-dev', it will work. > This what my guide currently suggests (including taking it out just > for release tags). I would *never* check in a release of 'Y' which mandated a non-released version of 'X'. >>> After branching for a release we can set the version (e.g., 1.2), >>> make a release, and tag the branch. >> We should not require branches. I would only bother creating >> maintenance branches when they are needed. > > +1 Agreed. Creating a release branch in SVN from a tag is trivial, and therefore shouldn't be required "ahead of time." >> Z, B, G, and I propose the following: > > Who's Z? :) > >> - Leave the version # out of setup.py on the trunk and on branches. >> >> When it is time to make a release, either from the trunk or from a >> maint branch: >> >> - Update changes.txt, adding a heading for the new # and date >> >> - Create a tag >> >> - check out or switch to the tag >> >> - Set the version in setup.py on the tag. Check it in. >> >> - Make the release from the tag. > > I could live with that, even with the fact that you'd be modifying a > tag, as long as it's done in this exact order and the only > modificdations to a tag woudl be setting setup.py. I'm fine with making "packaging only" changes to a tag. > I still see the development egg case the best argument for putting > the next anticipated version number into setup.py. I think the > compromise of version number + 'dev' marker would work best. I'd rather have no version number at all. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+vy1+gerLs4ltQ4RAv9TAKDR4/phUYakFY4WI0RgW1QN6QgQTgCeMBd2 BOy03oWEARIta+ye2AB5wPs= =PaEC -----END PGP SIGNATURE----- _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com