#1340 request to allow version downgrade of python-blivet in f21 alpha tc7
Closed None Opened 9 years ago by dlehman.

= phenomenon =
There was a build of python-blivet-0.62 on f21 that should have been 0.61.1. We "fixed" that by making the next build 0.61.1, but now that has caused a problem with the tc7 compose.

= reason =
When we branched python-blivet for f21 (upstream) there was a mishap. We branched at 0.61, so the first build on f21-branch should have been 0.61.1, but it was built as 0.62 in error. The code is equivalent to what would have been 0.61.1, but the version is 0.62. Now tc7 is blocked because the latest python-blivet version is 0.61.1, which includes three additional freeze exception fixes, and that is viewed as a version downgrade.

= recommendation =
This is a request to allow downgrading the version of python-blivet from 0.62 to 0.61.1 with a notice sent to the devel and test mailing lists telling users of branched that they'll need to do work to get the latest version. (dgilmore says 'yum distro-sync')

This request is to avoid carrying an epoch for a mishap in a pre-alpha version given that very few users are likely to have 0.62 installed -- fewer still who do not plan to reinstall at some point between now and f21 final.

dgilmore is waiting to start tc7, so all speed in consideration is appreciated.


Couldn't you just solve it upstream by releasing 0.62.1 that would be actually the same as 0.61.1 except the version?
Do I understand it correctly there was no real 0.62 upstream?

Anyway I am giving +1 to the version downgrade given there was no public Fedora release (not even Alpha) with the 0.62 yet.

Just release the F21 blivet version as 0.62.1. It's not like we're running out of integers and need to save the numbers here...

-1 to forcing a version downgrade in Branched/Rawhide.

Many of us (myself included) pull in updates constantly and have already upgraded to the 0.62 version (I just checked on my own systems). By allowing a version downgrade, anyone who updated to this version and hasn't paid close attention to the devel list (or run a distro-sync) will be stuck with a version that does not work until upstream finally gets around to a public 0.62.1 or higher release number.

Either have upstream jump ahead to 0.62.x or make an epoch change, but python-blivet does not get to be an exception to the upgrade policy. It will break systems and in the middle of Alpha Freeze is distinctly not the time to do this even if we were considering it.

If rel-eng is OK with it I will not stand in the way (so, I suppose, +1), but I do agree with the others that, considering that the Fedora package and upstream maintenance are so close, just bumping the revision on both branches appropriately is by far simpler, less likely to cause problems, and quicker because you don’t need to wait for a FESCo exception.

We branched at 0.61, so calling this 0.62.1 would be a bit misleading.

There was a 0.62 in rawhide from the master branch which has quite a few changes deemed too risky for f21.

we have the policy of not allowing packages to go backwards for a reason. To make sure the users can always update. This goes for rawhide and branched as well as it does for stable releases. I think that the version should be changed to 0.62.1 or an epoch added. I did tell dlehman to file a ticket if he wanted an exception to the policy. we ended up doing TC7 with the 0.62 build but we do need to get this resolved quickly.

I think that forcing users that installed the 0.62 version to do distro-sync outbalances the work needed to either bump the version to 0.62.1 upstream or to use epoch. What is exactly the reason you don't want to add epoch? To avoid carrying the epoch is not a reason. If you made a mistake, it is completely fine to ask you to fix it on your side, not to ask all the users to fix it for you.

-1 from me, unless you give me a really good reason to force all the users to run distro-sync.

We branched at 0.61, so calling this 0.62.1 would be a bit misleading.
There was a 0.62 in rawhide from the master branch which has quite a few changes deemed too risky for f21.

Right, I don't think anybody is advocating for bringing the risky unstable version to f21.

I would personally suggest to just relabel the release branches upstream so that the current 0.62 branch becomes 0.63, and the current 0.61 branch becomes 0.62. This way the code in f21 and rawhide stays the same, it just changes the version numbers.

Or bump the epoch number, if you think this makes more sense. After all, this is what epoch is for, to get out of these kinds of versioning issues.

-1 to the proposal to allow the version number going backwards.

I won't be able to attend the meeting today. I am thus revoking my +1 from above. I certainly prefer other ways to fix this problem now.

Replying to [comment:11 tmraz]:

I won't be able to attend the meeting today. I am thus revoking my +1 from above. I certainly prefer other ways to fix this problem now.

For the record, does that make your vote +0 or -1?

Decided in #anaconda that blivet will just do the epoch thing.

Login to comment on this ticket.

Metadata