Re: Epoch version for golang-github-gomodule-redigo-dev?
On 26/11/2020 09:31, Paul Gevers wrote:
> Hi Michael,
>
> On 26-11-2020 08:57, Michael Prokop wrote:
>> AFAICS we could:
>>
>> 1) use 2.0.0+really1.8.3 pattern for our Debian package version
>
> As it seems not unreasonable to expect the upstream version to go past
> 2.0.0 in the not infinite future, this is the approach I would take.
> Because you ask here, it suggests to me that doing this has some pain
> for the packaging that you didn't elaborate on. Why do you even raise
> the question here on debian-devel and don't just do this established way
> of fixing these kind of temporarily versioning issues in Debian?
Well, I was the one suggesting Michael start a discussion on
debian-devel about it, so I thought I'd chime in.
My reasonning is +really<version> seems to me to be a workaround when we
have to change the version number for Debian only reason - with no fault
of upstream. An example of this was the lack of transition in the last
freeze with a bunch of Go packages that were updated in unstable when
they shouldn't have, and had to be reverted.
Actually, I even suggested to use +upstream<version> instead, but I
don't know if that'd be allowed (as in understandable, clearer that
+really and as such, useful).
Also, we don't know if it's temporary, as Holger pointed out.
An epoch might be overkill here, but also seems more appropriate to me
since we have to work around upstream decision in this case. And since
the Policy states it needs to be discussed first here, I suggested to do
just that.
I do agreee that the best and most logical thing would be for upstream
to start using 3.0, as Simon pointed out. Michael, did you bring this
issue upstream ? Would you suggest this option to them ? If they're
willing to do that in a reasonable timeframe, we could go the +really
route and wait until 3.0 is available upstream. Otherwise, we can go for
an epoch if we reach consensus here.
Thanks to everyone participating, by the way!
Cheers,
--
nodens
Reply to: