Chris Withers wrote:
Martijn Faassen wrote:

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



Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to