[anser] 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. [albert] 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.