[Zope-dev] Re: Stable / Development branches?

[Chris Withers]

As always, Martijn has prettymuch hit the nail on the head with this 
mail, +lots to all the points he raises...

Chris

Martijn Faassen wrote:
> 
> I think we've concluded a number of things:
> 
> * some developers (Andreas in particular) do not consider it a huge 
> problem to keep maintaining an older version for some time longer, if 
> the fixes are relatively simple to apply.
> 
> * we really want to be a bit more careful with deprecating things. We 
> don't want to deprecate code in the transition from 2.8.4 to 2.8.5, for 
> instance, only with feature releases.
> 
> Perhaps these two points already help us go into the right direction.
> 
> The Five model of establishing new code in parallel to the existing Zope 
> 2 code was pretty succesful in not breaking stuff. Perhaps we should see 
> whether we can apply this more often.
> 
> On the other hand, the Five model of not changing the core also has 
> serious limitations. Some things Five is doing now are really dependent 
> on some core changes, and would be very hard to accomplish without them. 
> In addition, we're also interested in making larger bits of Zope 2 work 
> with Zope 3 code so we can stop maintaining two code bases. This 
> inevitably causes pain. I think the pain is necessary.
> 
> The pain should be kept under control:
> 
> * predictable pain. Predictable releases. Predictable deprecation 
> policy. Good communication of direction. I think we've been reasonable 
> at this.
> 
> * make it clear that pain leads to gains. We should communicate what we 
> *win* by making a change. Sometimes a change only is good for the Zope 
> maintainers, but often there are also potential neat things for Zope 2 
> developers. We should let them know. I think we've had some good 
> advocates for this, but perhaps we should have a clear location on the 
> zope website :) for this.
> 
> * make it clear how to make the pain go away. We should have better 
> documentation describing what a developer should do during an upgrade to 
> a new Zope version. I think we can do a lot better at this.
> 
> * optional buy-in pain. Follow the Five model where new code is 
> developed in parallel to the existing codebase, and you can opt into it 
> or stick with the old system. Sometimes this isn't possible. At other 
> times it's mostly a delaying action, but that might be useful 
> nonetheless. I think we've balanced this reasonably, but unfortunately 
> things like this are just not possible forever, as there's a maintenance 
> cost.
> 
> * soften the pain. If we can afford it, a longer maintenance period for 
> the Zope 2 platform might be nice. Andreas is sounding very friendly 
> about this, so that's cool. :)

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk