Hi, On Mon, Feb 20, 2017 at 09:25:17PM +0100, Richard B. Kreckel wrote: > On 02/20/2017 12:15 PM, Jonathan Wiltshire wrote: > > I specifically asked you not to use a "really" version. I don't mind so > > much for sid, but it's really nasty for targeting a release. > > I'm sorry. > > Jonathan, if I violated some policy, please point it out to me and I'll > respond *immediately*.
Merely preference, but not mine alone. > I am aware you asked me to pull an epoch. But it's been pointed out > elsewhere that epochs stick forever and I was asked to do a "really" > version instead. Where is this please? > Having a choice between 1) doing a "really" version and 2) pulling an > epoch, with one justification offered for 1) but none for 2) I opted for > option 1). Did I miss anything? Here is the justification then, which I'd happily have written if you'd asked: - this will hopefully be the final upload of shotwell into stable - the version number you have used says "I am 0.25, except that this is a lie and I am actually 0.24" (particularly unfriendly to users, and also doesn't translate) - stable is expected to last for at least the next 5 years, assuming LTS - ergo, the version number is a lie for 5 years. It can't even be fixed later in a point release By way of illustration, consider your version 0.25.4+really0.24.5-0.1, along with 0.24.5-1, 0.25.4-1, and (in future) 0.25.5-1. You end up with this order of upstream versions: 0.24.5 0.25.4 0.24.5-0.1 0.25.5 That is clearly very wrong, but you're stuck with it else nobody using stretch will see the new package. On the other hand, I am yet to see a good technical objection to epochs (it will be there forever is not a good objection). They are the accepted method (policy ยง5.6.12) of resetting the version number. This is why I don't mind a transitive +really version in sid to get out of a mess temporarily, but it is not suitable for a release. > I'm kindly asking that we work together to get this package of the > stable version in before the release, for the reasons pointed out in > #849688 and #850149. Poking around in a current stretch packages file reveals a number of packages pulling this trick, and I'm not about to go and file RC bugs against them all for this. Therefore, if you insist on using 0.25.4+really0.24.5-0.1 I will unblock it, but I'd still prefer an epoch. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51