Bug 172158 - Create an update to 2.1
Create an update to 2.1
Product: Fedora
Classification: Fedora
Component: python-cherrypy (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gijs Hollestelle
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2005-10-31 17:35 EST by Toshio Kuratomi
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-02 10:21:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Toshio Kuratomi 2005-10-31 17:35:07 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):

How reproducible:

Steps to Reproduce:
1. rpm -q python-cherrypy

Additional info:
Comment 1 Gijs Hollestelle 2005-11-01 06:56:28 EST
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.
Comment 2 Toshio Kuratomi 2005-11-01 10:49:11 EST
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.
Comment 3 Gijs Hollestelle 2005-11-01 11:20:34 EST
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.
Comment 4 Toshio Kuratomi 2005-11-01 11:50:29 EST
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.
Comment 5 Gijs Hollestelle 2005-11-02 04:33:45 EST
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.
Comment 6 Toshio Kuratomi 2005-11-02 10:21:47 EST
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 :-)

Note You need to log in before you can comment on or make changes to this bug.