Bug#1135785: Suggest starting date-based version numbers with 0.x

Hi!

On Tue, 2026-05-05 at 22:19:17 +0100, Simon McVittie wrote:
> On Tue, 05 May 2026 at 22:07:34 +0100, Ian Jackson wrote:
> > +	  <p>
> > +	    When upstream doesn't make numbered releases,
> > +	    consider starting the upstream part of the version number
> > +	    (as used in the Debian) with <tt>0.x</tt>.
> > +	    That way if upstream start making conventional releases,
> > +	    an epoch won't be necessary.
> > +	  </p>

For some reason I thought this was already documented somewhere, but if
it is, I cannot find it in either the Debian Policy or the Developer's
Reference. But in any case I think something like this should be
documented, yes.

> Won't this do the wrong thing when the "0.20260505" snapshot is
> superseded by upstream release 0.1 or similar? Upstreams don't
> always start numbering from 1.0, especially if they're using
> "semver" where 0.x releases have special semantics.
> 
> In some of my packages where the upstream has not yet made any
> releases (like src:openjk) I've used a version like 0~20260505,
> which avoids that.

I think 0~YYYYMMDD is the right pattern, because 0 sorts lower than
0.0 for example.

> I've also seen ~20260505 suggested, but I think that breaks the
> least-astonishment rule that a version number should usually start
> with a number.

But this one is not, because a version should start with a digit
(according to the Debian Policy and deb-version(7)), and otherwise
at least dpkg will emit warnings on these versions, but other tools
might outright reject them.

Thanks,
Guillem