On Wed, Dec 12, 2001 at 12:26:11AM +0100, Matthias Klose wrote:
> 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
^ Because it
is only in late beta and is not available as a zope
package, 2.5 is of no concern here.
> have a mission critical application, which is incompatible among zope
> versions, then you should install your own zope.
> Am I wrong here?
(Yes, you are... if this is the answer, then we should be packaging
zope only a 1) a toy with matching documentation or 2) not at all.)
I was not aware that a zope-2.1 was available. Look, I DO keep my
own Zope, for exactly these kinds of reasons. If you have thousands
of objects, each of which may break during an upgrade (an exageration,
but not much), you want to be very cautious. If you are out on a
limb for using something not from IBM or Microsoft, even more so.
I would prefer, very strongly, that Zope be version packaged, much
like python itself is. This would allow a gradual migration from one
version to the next. It is not even much more difficult to package
that way; the major difference is simply that there is a /usr/lib/zopex.x
and a /var/zopex.x. People who need to run multiple versions ought to
be able to figure out that they must be on separate ports, although
a bit of documentation would not hurt.
And, the time to cut over is not just before a freeze. Especially
as there is no reasonable migration path directly from 2.1 to 2.4.
I have been through a couple of version upgrades. Something has always
bitten me. Hard. Sometimes zope, sometimes 3rd party.
I would not care to be the fellow who had a mission critical application,
who 'upgraded', and found his site no longer working, with no way of
backing up to a working configuration.
For example, I serve technical drawings to essentially everyone in my
company. Loss of this would cost thousands of US dollars a day,
particularly as we no longer have a way to duplicate oversize drawings.
(It would also cause me much grief :-( .)
Upgrade compatiblity problems would be particularly a problem for
2.3 users in that when 2.4 comes from unstable to testing, no 2.3
.deb will be available, at all. 2.1 users could always go back to
the potato package. 2.2 users, well, I hope things went well for them.
Anyway, I will restate the rule that I would like to see followed.
Python is versioned. If a stable major version is in testing, at
any point during a release cycle, it stays there past the freeze.
For example, 1.5.2 is currently in testing. It stays there, with
documentation saying that it WILL be removed on the next cycle.
2.0 (well, consistency says I ought to make the same argument, but
I care very little. I know of nothing urgent that is purely 2.0
dependent.) That is, python2.x appear to be much alike, with few
upward compatibility problems.
Same with Zope. Note that zope point releases are often less
compatible than python major releases. 2.3 is in testing now.
We can be certain that 2.3 will be obsolete after woody is released.
Say so, and remove it from unstable after woody's release.
2.4 can coexist (in separate directories), so that is not particularly
hard. We can be pretty damned sure that 2.4 will be replaced
before the final freeze of woody; 2.5 final will probably be out in
three to four weeks. If this happens, document 2.4 as slated for
removal form woody+1, etc.
If zope were versioned, there is no reason we could not have a
2.5 beta package now; as it is, it is simply too risky.
Also note that, as I recall, 2.5 changes the User and UserFolder API's,
if you are using a third party UserFolder, you may have real
upgrade problems.
And Zope3 may be out before woody is finally released. From the
zope mailing lists, it is virtually certain that this will be a
major rewrite, with a willingness to break backwards compatibility.
Using a versioned zope gives people with large or important zope
sites notice, time (1.5 to 2 years), and the ability to migrate the
replacement of one version with the next, and the ability to revert
the site in an emergency. The major objection is size. But I
think that a versioned zope with appropriate 3rd party extensions
is not even all that large, as many extensions are not even
version dependent (I would guess no more than 2.5 Meg per version in total).
Jim Penny
>
> 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.
>
