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

[Jim Fulton]

On Sep 26, 2007, at 5:37 PM, 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.

You can always look at the previous tags or at CHANGES.txt.

>
>>> 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.

Good point.

> 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.
>
> 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.

Leaving aside for the moment the fact that "develop" eggs are used  
for system egg installs :(,

I think if a buildout uses a develop egg, there should be a very  
strong presumption that it it should be used. OTOH, if you have a  
part that depends on a previous major version, then you don't really  
want to use a develop egg for the later release.  This is a bit of an  
edge case though.

> 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).

A problem with this is that someone else might make a release of Y,  
either to fix a bug or to add a feature while your working on the new  
feature in Y.

>>> 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
>
>> 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 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 agree that the develop egg case is problematic.  I'd like to think  
about that.

If you ever actually make dev releases, then guessing wrong about the  
next version could cause real problems.  Consider the following case:

We've just released 1.1. We guess the next release is 1.2.  We change  
things and release, 1.2dev-r#####. Someone fixes a bug and releases  
1.1.1.  Now there's a dev release of 1.2 that is actually older than  
the 1.1.1 release but that setuptools considers to be newer.  I think  
this is fairly problematic.  Then again, I think that dev releases  
are problematic in a lot of ways.

Jim

--
Jim Fulton
Zope Corporation