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
_______________________________________________
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 )
