Red Hat Bugzilla – Bug 172158
Create an update to 2.1
Last modified: 2007-11-30 17:11:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7
Description of problem:
A new version of cherrypy has been released. It has a lot of desirable new features but is also backwards incompatible in some ways. I would like to see the new cherrypy in devel. I'd like to see it for FC-4 as well, but it may require some thinking on parallel installing to do so.
What are your thoughts as the maintainer?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rpm -q python-cherrypy
I had already committed my CVS update to 2.1.0 before reading the bugzilla
entry, I have also updated the package for FC-3 and FC-4.
I hope that the people who are using it right now all know about the backwards
incompatibility (it should take only a few minutes to port an existing site). Is
there any general policy for this? I have already requested the build for FC4,
I'm trying to cancel the build now to delay this update util I know what to do
about the backwards compatibility.
There's no general policy so as package maintainer you have final say. But it
is somewhat bad form to have an update that is known to not be a drop in
replacement. The usual solution is to have parallel installable package for old
and new versions. Then I can import cherrypy20 and get the old behaviour.
In most cases, if an older, incompatible package already exists for a FC
release, the new one gets renamed if there's an update for that release. Then
in the next FC release the renaming switches. So for cherrypy it would be
FC3 & FC4: cherrypy = cherrypy-2.0; cherrypy21 = cherrypy-2.1
devel: cherrypy = cherrypy-2.1; cherrypy20 = cherrypy-2.0
FC6+: Unless there's a real need for the older cherrypy, drop it.
This gives users a transition period in which to adapt their code. Sometimes
there is simply a transition between Core releases and users are warned they
need to update their code when making the transition betwwen FC4 and FC5. I
wouldn't encourage that, though. Consider a web hosting company which has users
building with cherrypy-2.0. When they upgrade packages they will have to
specially exclude cherrypy from updating until they've built cherrypy21 and
allowed their users to migrate.
This would call for 3 different packages and a confusing naming scheme, I wonder
i f this is worth it. I think that anyone that is seriously using cherrypy will
want to upgrade to 2.1.
The changes required to make an existing site work are pretty straight-forward.
I suspect not that many people are using the package in a big deployment setting
(like your web hosting example yet), given the fact that this is the first
bugzilla entry ever to be opened for it. I hope to just upgrade the
python-cherrypy package to 2.1 and include some useful pointers to how to
upgrade sites in the changelog.
You could make it two packages to minimize the impact.... Just a
python-cherrypy20 package to have a backwards compatible option.
Collecting information into a file in %doc might be a good idea -- though it
depends on the person whether they search %doc or the web first :-)
It could be that there aren't many big deployments yet but if there are, a
painful upgrade will make them reconsider using python-cherrypy on Fedora....
But this is your call as maintainer.
I'm sorry but all my attempts to kill the upgrade (using plague-client and by
sending an email to people that should be able to remove it from the build
system) failed. In other words the update is now out there for FC-4 and it will
take adding an epoch to make it go away.
So I found :-/ Have you seen the other bug I found with the pointer to
upstream's bug tracker? There's two patches in upstream's tracker that fix the
issue. I'm not sure if either is acceptable to upstream yet. If one is I'll be
bugging you for a 2.1.0-2 release :-)
If not, I guess there'll be some mad packaging going on here to create a
python-cherrypy20 package so my sites can continue to function. I'll bug you to