[Zope-CMF] GenericSetup backport

[Godefroid Chapelle]

Le 27/05/11 10:03, Hanno Schlichting a écrit :
> On Thu, May 26, 2011 at 10:39 PM, Godefroid Chapelle
> <gotcha at bubblenet.be>  wrote:
>> Le 26/05/11 17:15, Hanno Schlichting a écrit :
>>>> Smaller 1.4.x numbers could be kept for bug fix releases for CMF 2.1 and
>>>> Plone 3.
>>>
>>> That's a really weird way of doing it. And I'm a -1 on that.
>>
>> I agree it is a bit weird, I am just trying to be creative to comply with
>> your request of preserving Plone 3 tests.
>>
>> Outside being weird, can you explain issues you have ?
>
> You want to backport a feature that is known to break things into a
> stable release series.

It does not break things, this is too wide.

GS test suite was not touched outside places where tests did check 
internal implementation.

It would be much more fair to state that it is known to break tests setup.

> To me that's just wrong and defeats the very purpose of having stable releases.
>
> Hanno

What I am actually trying to understand is which versions to give to 
public releases after forking an existing branch.

The numbering scheme of those versions should fill the following goals :

- systems that depend on releases of the original branch should not be 
impacted.

- new releases of the original branch should be "pullable" without the 
need to touch the existing systems.

- releases of the newest branch should have their own numbering so that 
other packages can state unambiguous dependency on those new releases.

This is what dev releases are for (as you suggested).

My proposal is then the following : I would publish a 
Products.GenericSetup 1.4.6dev001 release from my backported branch to PyPi.

And have p.a.testing 3.0.x depend explicitely on this GS 1.4.6dev001 
release until there is a need for a new release of GS from this 
backported branch.

Opinions ?

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be