hmm, then we have to keep zope 2.1 as well (the version from potato). Why do you want to keep 2.3, not 2.2? Why not 2.5? IMO If you have a mission critical application, which is incompatible among zope versions, then you should install your own zope. Am I wrong here?
Jim Penny writes: > I have a zope 2.3 site. My best guess is that to upgrade it to > zope2.4 is going to be a three day (24 working hour) process. I > cannot just take it down for three days at my convenience. This > will have to wait until there is a plant shutdown. > > I suspect that anyone who has a lot of labor invested in zope 2.3 is in > a similar circumstance. I am not sure that the upgrade process has been, > nor even can be, fully automated; particularly if the user still has > the older pythonscripts, rather than the Script (Python). > > For similar reasons, I can see someone beginning a migration to zope 2.4 > and then having to backtrack to 2.3 to get the site back on-line fast > enough. In fact, I would have been far more comfortable had zope been > versioned, so that both a 2.3 and a 2.4 could exist concurrently. This > would make site migration far easier, as the older site could be peeled > off folder by folder and tested that way, with less fear of major > disruption. > > If we are to argue that python is "mission critical" and that "mission > critical applications" are to be built on it; then we have to behave > that way. And one implication of this is that we have to be very > conservative in dropping old major releases. A two year lead time > notice seems not at all unreasonable. That is, put a prominent notice > that the package will be withdrawn two years from now. Put in in both > the Debian README, and in the python-doc front page. > > Then, if someone comes back whining that their application no longer > works after that date, well, at least they will have been put firmly > on notice of the deadline, with enough lead time to do something > about it.
