Re: Epoch bump for golang-github-valyala-fasthttp
On 12/11/2021 16:26, Guillem Jover wrote: On Fri, 2021-11-12 at 10:55:26 +0530, Pirate Praveen wrote: On 12 November 2021 12:38:23 am IST, Guillem Jover wrote: The golang-github-valyala-fasthttp package used to have date-based release numbers (current Debian version 20160617-2). Upstream has since switched to semver (latest upstream version 1.31.0). So the version scheme has been reset, and unfortunately given that no prefix was used when initially packaging this, an epoch seems to be in order now. I'm planning on updating in the coming days to the latest upstream release and bump the version using an epoch. How about golang-github-valyala-fasthttp-v1 ? Though it won't match import path, it can avoid the epoch. While interesting, I think this might be worse. I'm not a fan of epochs, but this is precisely the case they were intended for. Indeed, I think an epoch bump here is sensible. Cheers, Emilio
Re: Epoch bump for golang-github-valyala-fasthttp
On Fri, 2021-11-12 at 10:55:26 +0530, Pirate Praveen wrote: > On 12 November 2021 12:38:23 am IST, Guillem Jover wrote: > >The golang-github-valyala-fasthttp package used to have date-based > >release numbers (current Debian version 20160617-2). Upstream has > >since switched to semver (latest upstream version 1.31.0). > > > >So the version scheme has been reset, and unfortunately given that no > >prefix was used when initially packaging this, an epoch seems to be in > >order now. > > > >I'm planning on updating in the coming days to the latest upstream > >release and bump the version using an epoch. > > How about golang-github-valyala-fasthttp-v1 ? > Though it won't match import path, it can avoid the epoch. While interesting, I think this might be worse. I'm not a fan of epochs, but this is precisely the case they were intended for. The way I see it, the source package name is now burned, and even if we played games and used a different source+binary name w/o epoch, but breaking the current convention and expectation of package names trying to map closely to import paths, the current source+binary one could/should not be reused anyway, so we might as well bump the epoch there, and if in the future there's a «.v1» kind of import path bump, then we can simply drop the current one and completely get rid of the epoch. > Most projects change import paths on incompatible bumps. But this didn't happen upstream in this case. Thanks, Guillem
Re: Epoch bump for golang-github-valyala-fasthttp
On 12 November 2021 12:38:23 am IST, Guillem Jover wrote: >Hi! > >The golang-github-valyala-fasthttp package used to have date-based >release numbers (current Debian version 20160617-2). Upstream has >since switched to semver (latest upstream version 1.31.0). > >So the version scheme has been reset, and unfortunately given that no >prefix was used when initially packaging this, an epoch seems to be in >order now. > >I'm planning on updating in the coming days to the latest upstream >release and bump the version using an epoch. How about golang-github-valyala-fasthttp-v1 ? Though it won't match import path, it can avoid the epoch. Most projects change import paths on incompatible bumps. >Thanks, >Guillem > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
