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

[Martijn Faassen]

Chris Withers wrote:
> Martijn Faassen wrote:
>>> +1
>>
>> Extending the maintenance period for older branches indeed sounds like 
>> a good idea.
> 
> Hang on, that makes things even worse for the already-stressed 
> developers though. The branches there are combined with the longer 
> they're stable for gives you the "developer stress".

Yes. This is all dependent on the assumption that there are developers 
interested in maintaining the older versions. If these developers do not 
exist, we have a problem.

It's clear that the picked up speed of development of Zope 2 is 
stressful for developers at some point. No development of Zope 2 is bad 
for the platform, and thus stressful for developers on the longer run 
who will either have to learn something new, or have to maintain a 
"frozen" Zope 2 all by themselves.

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

Regards,

Martijn