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): python-cherrypy-2.0.0-2 How reproducible: Always Steps to Reproduce: 1. rpm -q python-cherrypy 2. 3. Additional info:
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 something like: 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 review :-)