Re: Adding epoch to kworkflow package to correct a wrong upstream version
On Sun, 12 Mar 2023 at 09:15:35 +0100, Tobias Frost wrote:
> On Sat, Mar 11, 2023 at 06:35:39PM -0700, Rodrigo Siqueira wrote:
> > While working on a new version of the kworkflow package
> > (https://tracker.debian.org/pkg/kworkflow), we noticed that the current
> > version is 20191112-1.2, and the latest upstream version is 0.6.2.
>
> I've got recently a very similiar situtation with
> gnome-shell-extension-autohidetopbar, as there it was considered ok to use an
> epoch.
Yes, this sort of situation is what epochs are for.
> > Version 20191112-1.2 was created because the upstream had no official
> > release at that time; for this reason, the 20191112-1.2 was created and
> > named based on a date.
In future, please use a lower version number when packaging unreleased
software. A version starting with an 8-digit date is almost guaranteed
to compare greater than whatever upstream eventually chooses, and
therefore require the use of an epoch.
I generally represent date-only versions (like src:darkplaces) or
snapshots of software with no releases (like src:openjk) as 0~YYYYMMDD,
sometimes adding a suffix with the truncated git sha1 (for example see
darkplaces_0~20180908~beta1-5 and openjk_0~20230306.ab77102+dfsg-1).
That means if upstream decide to go from datestamped snapshots to any
reasonable "semantic" version number (even 0.0.1), I won't need an epoch.
smcv
Reply to: