-----BEGIN PGP SIGNED MESSAGE-----
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
>>>> 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
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
> 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.
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 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
-----END PGP SIGNATURE-----
Zope3-dev mailing list