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
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
