[Zope3-dev] Re: faulty releases and pypi access [update]

[Tres Seaver]

-----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          tseaver at palladion.com
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-----