[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Epoch bump for kworkflow

Hi João,

João Seckler <jseckler@riseup.net> (2021-04-13):
> I am currently in process of updating the kworkflow package[1][2]. I am
> having issues providing a debian/watch file for the following reasons:
> - Upstream maintains no tags nor releases. I am in touch with them to
>   ask them to create tags or releases;
> - Current version of the package is 20191112-1.1. The date in it doesn't
>   seem to be related to any information provided by the upstream;
> - Even if upstream isn't willing to use tags or releases, the
>   alternative "go-like" version of the package, gathered from the latest
>   upstream commit (0.0~git20201226.e30ce3a), compares erroneously to the
>   current version format.
> By suggestion of sergiodj and kanashiro, I intend to use an epoch when
> versioning future releases of this package, which will allow the
> adoption of a more sensible version format.
> Any feedback is welcome.

What about using a similar versioning scheme but without the 0.0~git

Going for 20201226.e30ce3a(-1) or something similar would sort higher
than the current version number, and you could just wait for an
hypothetical switch to a “tag/version-based format” to introduce the
epoch? Introducing an epoch and an artificial 0.0 release right now
would seem a little odd to me.

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply to: