I can't quite help wondering whether someone at DC has maybe gotten so
"into" the development of Py 2.1 that they just can't wait to use its new
stuff, whether it's objectively what's best for Zope or not.  The prudent
thing to do would have been to add features as needed using
1.5.2-compatible code, or at best to offer a "new18n" branch that requires
2.1, which people who are THAT desperate for i18n could choose to follow if
they wanted.  Then, say 6-12 months after 2.1 is gold, you could unify and
require it for 3.0.  Instead, for the sake of being able to let the Python
developers stick a Zope logo on the 2.1 release, we are risking a boatload
of trouble.

As far as I can make out the strategy you advocate is more or less exactly
what they *did* do - so smoothly you didn't even notice.

The *big* leap is from 1.5.2 to 2.0 which has been out for quite a while.
I18N is *desperately* needed but had to be delayed because of the
compatability problems you are rightly concerned about. So even after
I18N became feasible with 2.0 the main branch was made compatible
with using 2.0 but binaries released with 1.5.2 to avoid risking a
boatload of trouble while enabling people desperate for I18N to start
using 2.0 and at the same time discover as much as possible of the
hiccups before general switchover.

Waiting for the "odd numbered release" is also a generally sound
policy. Essentially you are confusing that prudent delay in
completing the smoothly planned (and very clearly announced long ago)
switch from 1.5.2 to 2.x with a sudden rush to 2.1. Whatever
problems do occur will be overwhelmingly from the 2.x, not from
it being 2.1 in particular.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to