I would like to suggest the Debian Policy to recommend a specific
Debian package version string scheme in cases where upstream has no
releases, but they do have git commit ids to refer to:

***
In case your upstream does not use version numbers, the Debian package
version will look like this: 0.0~git20130606.b00ec39-1

* The 0.0 in the beginning is used to allow upstream to adopt version
numbers at any point in time and also to make it clear that no
traditional version number is used for this package.
* The second part is the version control system, e.g. git, hg, svn.
* Afterwards, a date follows in the format YYYYMMDD.
* After the dot, the version control system revision follows, to make
it clear which commit was packaged, as many repositories have multiple
commits on a given day.
* The last part after the dash is the Debian version number.

In case you make more than one snapshot per day, you can append a
snapshot number after the date, e.g. 0.0~git20130606.2.b00ec39-1. This
should rarely be necessary.
***

The text above is from https://go-team.pages.debian.net/packaging.html
but I see also packages outside Go team adhering to this scheme
already.

± grep --only-matching -P '/.*0.0~git.*.deb' Packages | head
/main/a/arpys/python3-arpys_1.0.0~git20230217101414.07b63b3-2_amd64.deb
/main/a/asmjit/libasmjit-dev_0.0~git20231115.1da9e4d-1+b1_amd64.deb
/main/c/c-vtapi/libcvtapi-dev_0.0~git20230329.226eda8-1.1+b2_amd64.deb
/main/c/c-vtapi/libcvtapi1t64_0.0~git20230329.226eda8-1.1+b2_amd64.deb
/main/c/canid/canid_0.0~git20180613.007c9af-2+b28_amd64.deb
/main/c/cht.sh/cht.sh_0.0~git20220418.571377f-2_all.deb
/main/c/cisco7crack/cisco7crack_0.0~git20121221.f1c21dd-3_amd64.deb
/main/c/cl-fiasco/cl-fiasco_0.0~git20200514.bb47d2f-3_all.deb
/main/c/cpuinfo/cpuinfo_0.0~git20240830.fa1c679-5_amd64.deb
/main/c/cpuinfo/libcpuinfo-dev_0.0~git20240830.fa1c679-5_amd64.deb


I am happy to submit an exact patch for the policy to write the final
version of the text in the correct place, assuming I see some general
support for having this included as replies here.

[...]

Please recommend only putting this information into the changelog entry.
It has no place in the version value.

Sorry, I don't understand, can you elaborate?

In the case of say for example canid 0.0~git20180613.007c9af-2, which
part of this version string do you think does not belong there and
should be removed?

The commit hash. 007c9af.

OK, thanks.

I disagree here - to me the git commit hash is the single most
important identifier for the software version if there are no actual
releases.

Otto Kekäläinen <otto@debian.org> writes:

FWIW, I used to believe the same but this changed my mind -- gnulib is a
rolling stable package with no releases:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069268#10

I believe versions numbers are for humans; incremental integers, dates
and possibly semantic versioning are useful ideas.  I don't object to a
git commit identifier in a version number, but I also wouldn't want to
enforce it as a general rule.  For gnulib I settled on recording the
full git commit identifier in debian/changelog instead.

/Simon

I do think the commit ID is valuable. In case there isn't a friendly
number, then the commit ID is the actual identifier of what you're
running.

But git commit IDs are 'random' and so they're useless for sorting
purposes, which is essential when checking for a newer version and for
`dpkg --compare-versions` to work.
Thus adding the date is needed for that. But the date itself is only an
*indication* of what you're actually running.

If a rule is proposed to Policy, then it needs to account for such a
situation and should therefor require an incremental number, which again
is needed for proper sorting/comparing.

It's also better for (potential) tooling when the format is consistent.
And I like consistency in general.

Cheers,
  Diederik

I have tried this approach, and ended in situations where the git hash
was directly damaging: Imagine the above, but with a random hash instead
beginning with "1", e.g. 0.0~git20130606.2.b00ec39-1 coming after
0.0~git20130606.1dffba21-1.  That won't work.

Then you could introduce a special delimiter, essentially abusing the
real purposes of those delimiters, e.g. 0.0~git20130606~+1dffba21-1
and 0.0~git20130606.2~+b00ec39-1.  But then you may (like I did) run
into your chosen "semaphor" clashing in similar way, but this time
baked into helper tools that are difficult to bypass for that rare
occasion that you are in just now: See section on "grouped package" in
man page for uscan for the real existing potential for clash I ran into.

A version number *must* be not only unique but also incremental. A
git has is fundamentally not incremental, so poses a real risk of
getting in the way of constructing robust version numbers.  And for
which benefit? Ensuring uniqueness? It is already unique that
0.0~git20130606-1 and 0.0~git20130606.2-1 are the first and second
Debian snapshot issued that day, and to know what that corresponds to
upstream, you already need not only a git hash but also a git repo URI.

I have come to view git hash in version string as a vanity identifier,
similar to "clarifying" paranthetical notes in OpenPGP identifiers
like "Jonas Smedegaard (Debian work) <dr@jones.dk>".

Please let's discourage (not promote) those, and certainly let's not
bake them into Policy.


 - Jonas

"Diederik de Haas" <didi.debian@cknow.org> writes:

If the policy should say anything regarding multiple new upstream
release uploads per day for a single package, I would prefer if it
instead said "Go and work on your QA process, or take a break for one
day to let upstream stabilize before you package it".

/Simon

On Sun, 01 Dec 2024 12:58:41 +0100 Jonas Smedegaard <dr@jones.dk> wrote:
 > On Thu Nov 28, 2024 at 10:44 AM CET, Simon Josefsson wrote:
 > > In case you make more than one snapshot per day, you can append a
 > > snapshot number after the date, e.g. 0.0~git20130606.2.b00ec39-1.
 > > This should rarely be necessary.
 >
 > I have tried this approach, and ended in situations where the git hash
 > was directly damaging: Imagine the above, but with a random hash instead
 > beginning with "1", e.g. 0.0~git20130606.2.b00ec39-1 coming after
 > 0.0~git20130606.1dffba21-1. That won't work.
 >
[...]
 >
 > A version number *must* be not only unique but also incremental. A
 > git has is fundamentally not incremental, so poses a real risk of
 > getting in the way of constructing robust version numbers. And for
 > which benefit? Ensuring uniqueness? It is already unique that
 > 0.0~git20130606-1 and 0.0~git20130606.2-1 are the first and second
 > Debian snapshot issued that day, and to know what that corresponds to
 > upstream, you already need not only a git hash but also a git repo URI.
 >
 > I have come to view git hash in version string as a vanity identifier,
 > similar to "clarifying" paranthetical notes in OpenPGP identifiers
 > like "Jonas Smedegaard (Debian work) <dr@jones.dk>".
 >
 > Please let's discourage (not promote) those, and certainly let's not
 > bake them into Policy.
 >

I agree that forcing the date-commit format is not the way to go imo.

It's not that often the case that a packages with no releases has two
commits in a day,

and I doubt that most packagers would run into this.

While I agree on the 0.0~git prefix I'd argue that the date is
sufficient. As pointed out

it sorts with dpkg and if someone is really wants to know which exact
commit they have they can get it from

salsa.

Recommending the data+hash format is certainly a not a bad idea, though
I really think date as single identifier suffices.


best,


werdahias

This bug report makes a good point that version should be kept to be copy-pastable and
comparable by humans.

By itself, the git commit hash does not provide any information without a copy
of the git repository. debian/changelog should be sufficient for that purpose.

Cheers,

If that is a regular occurrence, then I agree.

But people make mistakes.
Or if it's a high-impact security issue, then getting *a* solution out
the door quickly is possibly preferable to waiting till you get the
perfect solution. And that can be followed up by a bit better, but still
not perfect solution, on that same day.

My 0.02

"Diederik de Haas" <didi.debian@cknow.org> writes:

Sure, and I don't see the above statement disallowing that.  For such a
situation, you could make up a new upstream version number that is
appropriate for the situation.  For example, 0.0~git20230606a-1 and
0.0~git20230606b-1.

/Simon

Is there a reason to use 0.0 here in preference to just 0?
(For example see src:darkplaces, src:openjk)

This can go wrong if an upstream switches from svn or hg to git (or
hypothetically, from git to bzr or fossil or something else earlier in
the alphabet). ioquake3 had a problem like this already: ioquake3 did have
releases in the past (but hasn't had a formal release for a long time, not
even to fix security vulnerabilities), so we're using snapshot versions
starting with 1.36+ instead of 0~, but otherwise it's the same pattern.

In ioquake3, versions like 1.36+svnYYYYMMDD were superseded by what would
have been 1.36+gitYYYYMMDD if it hadn't broken the sorting order. I worked
around this by using 1.36+uYYYYMMDD (u for "upstream git"); another
possibility would have been 1.36+vcsYYYYMMDD.

    smcv

I'm not sure if this should be in Policy, but it might make sense to
document as "best practice" in the devleopers referrence?

I'm not sure if this should be in Policy, but it might make sense to
document as "best practice" in the devleopers referrence?

Hello,

Yes, I was thinking the same.  Let's reassign this bug?

Please no. Rather close it and state that you do not accept this in
the policy so that there is an audit trail that this was rejected from
policy and who made the decision.

Updates/changes elsewhere can then refer this bug as a source that
there is no policy for version strings of this sorts. Or more people
can chime in and request it to be re-opened etc.

I assume some of the maintainers of nearly 900 packages currently
using this might have an interest to see that the policy was rejected:
± curl http://ftp.debian.org/debian/dists/sid/main/binary-amd64/Packages.xz
| unxz > Packages
± zgrep --only-matching -P '/.*0.0~git.*.deb' Packages | wc -l
893

Hello,

Policy and the Developers Reference are developed side-by-side.  They
use the same mailing list.  We share DebConf BoFs.  It's normal for us
to move bugs back and forth between the two depending on where something
would best fit.

This would not constitute any sort of rejection for which maintainers of
packages would need to be concerned.  It does not mean anyone's
practices should change.

It does not mean that there is no policy (lowercase 'p') for these
version strings in Debian.

Hi,
inclusion specifically due to the normative status, so I can write for
example a Lintian check for it.

I am not requesting documentation on the topic to be written - that
can be done separately and the request for documentation would have
different contents, and probably a patch with specific contents for
the Developers Reference and not a bug report at all since only the
Policy updates require bug reports to be used.

My intent here was to suggest specifically that the version of form
0.0~git20130606.b00ec39-1 would be elevated as the Policy recommended
form, as it makes sense and is already most popular.

All version control referencing version strings:
± grep --only-matching -P "^Version:
.*(commmit|git|hg|svn|darcs|csv|dev).*"  Packages | sort | uniq | wc
-l
1818

~30% using this exact format already:
± grep --only-matching -P "^Version:
[0-9.]+~git[0-9]{8}\.[0-9a-f]{5,9}-.*" Packages | sort | uniq | wc -l
665

For reference as list of related version strings in current unstable:
± grep --only-matching -P "^Version:
.*(commmit|git|hg|svn|darcs|csv|dev).*"  Packages | sort | uniq
Version: 00.01.02+git20170220.e6d2e9b+dfsg-5
Version: 0.0.0+2016.01.15.git.29cc9e1b05-2+b14
Version: 0.0.0~20210101.git55fe226-2
Version: 0.0.0~git200730-1.1+b1
Version: 0.0.0+git20130306.9fc39e0-4
Version: 0.0.0+git.2014.09.15.7d6d7bd7eb-5
Version: 0.0.0+git.2014.12.04.eb4090f265-3
Version: 0.0.0-git20150806-9+b2
Version: 0.0.0+git.20180227.3a1d648-1
Version: 0.0.0+git20180419-2.1
Version: 0.0.0+git20180914.61c9d02e-2+b5
Version: 0.0.0~git2019.06.13-2
Version: 0.0.0~git20210103-1+b2
Version: 0.0.0+git20210107.1933e76f-1
Version: 0.0.0+git.2021.03.30.1a3320dab9-3
Version: 0.0.0+git.20220602.a2552c5-2
Version: 0.0.0+git.20220602.a2552c5-2+b1
Version: 0.0.0~git20220912.a15b489-2
Version: 0.0.0~git20230215.21a85fe-1+b1
Version: 0.0.0.svn147-2+b1
Version: 0.0.0+svn4922-1
Version: 0.0.0+svn654-1
Version: 0.0.10-rc5+git20230513+d3e6d4f-2
Version: 0.0.12-rc5+git20230513+5581005-1
Version: 0.0.13~git20230419+dfsg-3
Version: 0.016+git20210310.42d4f9f2-1
Version: 0.0.19+git20140108.7211484-6
Version: 0.0.1+git20160123.62.889391d-1.1
Version: 0.0.1+git20161023.60.deb8c38-1.2
Version: 0.0.1+git20170413.ccd079d-3
Version: 0.0.1+git20170705.2c962ac-4
Version: 0.0.1+git20190125.bfd5418-1+b2
Version: 0.0.1+git20190125.c83d1e9-2.1+b1
Version: 0.0.1+git20190320.5ae3a3e-3.6
Version: 0.0.1+git20190830.eec2864-3+b2
Version: 0.0.1+git20191219.98458ce-3+b2
Version: 0.0.1+git20201202.1b6eddf-1.2+b2
Version: 0.0.1+git20230914.4b4cd3b-2.1
Version: 0.0.1+git20240726+ds-1
Version: 0.0.20051227svn-13+b1
Version: 0.0+20140524.git7dcd86-4+b1
Version: 0.0+20190501.git986658-6
Version: 0.0.2+git20130809.8062ee1-4+b2
Version: 0.0.2+git20161004.f62483c-3
Version: 0.0.2+git20170626.21.b2862e3-4
Version: 0.0.2+git20170626.21.b2862e3-4+b3
Version: 0.0.2+git20190404.eea2584-3
Version: 0.0.2~git20230904.39efe44+dfsg1-2
Version: 0.0.2+git20241118.fd50624-1
Version: 0.0.3~git20120910.1519bfe-4
Version: 0.0.3~git20131224.f3c78ba-3
Version: 0.0.4+git34dfe43-4
Version: 0.0.6+git20140421.b3a423f-4
Version: 0.0.6+git20230504.1ba7d5a0-1
Version: 0.07.2.svn396+dfsg-18
Version: 0.07z+git20201202+bb7c3f8-2.1
Version: 0.0.8-rc5+git20230513+afc4a5f-1
Version: 0.0+git200150803-6+b2
Version: 0.0+git20090728.a936bacf-8+b1
Version: 0.0~git20120228.dcc0709-2
Version: 0.0~git20120716-4
Version: 0.0~git20121217.1dbdf83-3
Version: 0.0~git20121221.f1c21dd-3
Version: 0.0~git20130314.0.01d012b-2.1
Version: 0.0~git20130427.0.53be0d3+dfsg-7
Version: 0.0~git20130605.792643-5
Version: 0.0~git20130607.0.96e4ba3-3
Version: 0.0~git20130702.0.ac974c6-6
Version: 0.0~git20130720.0.c70c1f2-1.1
Version: 0.0~git20130729.604e922-4
Version: 0.0~git20130729.9e5f7f4-3
Version: 0.0+git20130823.de420fa-3
Version: 0.0~git20130923.0.a98ad7e-3
Version: 0.0~git20131003.0.24d7ef3-4.1
Version: 0.0~git20131221.0.179d4d0-5
Version: 0.0~git20140119-2
Version: 0.0~git20140120-3
Version: 0.0~git20140121-4
Version: 0.0~git20140218.13f4951-4
Version: 0.0.git20140301-6+b15
Version: 0.0~git20140312.0.f693c7e-2.1
Version: 0.0~git20140401.3eca13d-1.1
Version: 0.0~git20140412.0.ecf753e-2
Version: 0.0~git20140419.0.cca7078-1.1
Version: 0.0~git20140422.9fd32a8-1
Version: 0.0~git20140508-5
Version: 0.0~git20140515.f408b00-1.1
Version: 0.0~git20140617205143.9758f70-4
Version: 0.0~git20140626.e9e8d98-3
Version: 0.0~git20140818.0.3dcccbd-2
Version: 0.0~git20140819-2
Version: 0.0~git20140829.066b75c-2
Version: 0.0+git20140929.e5b585a-6
Version: 0.0~git20141007.0.ecd9b78-5.1
Version: 0.0~git20141008.0.6352e00-7
Version: 0.0~git20141008.0.7a24ed7-9
Version: 0.0~git20141013.ed2d14c-3
Version: 0.0~git20141024.0.dd63297-8
Version: 0.0~git20141208-4
Version: 0.0~git20141208.c03a2fa-3
Version: 0.0~git20141217.14bf14c-4
Version: 0.0~git20141217.69aee45-3
Version: 0.0~git20141218.2.4bc0091+dfsg1-4.1
Version: 0.0~git20150106.0.6724a57-2.1
Version: 0.0~git20150107.0.dcfedd5-4.1
Version: 0.0~git20150109-3
Version: 0.0~git20150115.0.2404f77+dfsg-5
Version: 0.0~git20150121.0.ab3940c-1.1
Version: 0.0~git20150214.0.9440f19-2.1
Version: 0.0~git20150214.217e25f-4
Version: 0.0~git20150225.0.68e9c06-4
Version: 0.0~git20150304-2
Version: 0.0~git20150311-3+b2
...
(truncated)
...
Version: 3.0.0~20240125git1200598-1
Version: 3.0.0~20240125git1200598-1+b2
Version: 3.0.0~3.13.1~git20230831-2
Version: 3.0.0+git13-g7f7ad47-1+b2
Version: 3.0.0+git20171022.9aa4983-2
Version: 3.0.0+git6-0.6
Version: 3.0.10+git20130108.4ca41f4-1
Version: 3.0.1+git.20120229.bda06a3f-2
Version: 3.0.1+gitdb9e868-2
Version: 3.04~git20220826.cda2db4+dfsg-2+b1
Version: 3.04+git20240613-1+b1
Version: 3.0.7+git.20130130.97b34ece.REALLY.1.0.3-3
Version: 3.0.7+git20151023.72.a0ff256-4
Version: 3.0.7+git20151023.72.a0ff256-4+b11
Version: 3.0.7+git20220909+dfsg-6
Version: 3.0+git20190531-13.1+b5
Version: 3.0~git20221205.d588019+dfsg-1.1
Version: 3.0+git20230924.1bbce67-2
Version: 3.0+git91419a7-2
Version: 3.0+svn80-5
Version: 3.10.3+git20180306-1.1+b2
Version: 3.1.0+git20160608.605b357+~cs0.6.2-2
Version: 3.11.92+git20230129.d59dc92f-1+b2
Version: 3.13.1~git20230831-2
Version: 3.14.1630+git20240609.adc080d-1
Version: 3.14~alpha0+svn3576-2
Version: 3.1.5+git20210713.6e53b66-2
Version: 3:1.6.0+git20230823.8dce1e3-2
Version: 3.17.4~next.0~1.0.0~git20230424.1320922-3
Version: 3.1+git20160228.0.41961ce-1.1
Version: 3.1+git20221204-2
Version: 3.20+git20240209.8710add+dfsg2-1
Version: 3.2.2+git20220101+07e6509cc6bf-2
Version: 3.2.5+20221017git493ec88+~cs4.0.9-1
Version: 3.2.5~3.13.1~git20230831-2
Version: 327+git20240901-1
Version: 3.2+git20231203-2
Version: 3.3.0+really3.3+git20241031.d00c062-1
Version: 3.3.3.post1+git202411101249.168ac48-1
Version: 3343+svn3400-6
Version: 3.35+git20191126.5a8eaf4-2.2
Version: 3.3.9+svn20110818.r1732-6.2
Version: 3.3+git20220708.9ec59c9-2
Version: 3.4.1+git20201022.a0d3415c-1.2
Version: 3.4.1+git20201103.0836f5d1-1+b1
Version: 3.43~svn170+dfsg-7
Version: 3.43~svn170+dfsg-7+b1
Version: 3.5+git20160707.1.e46042e-1+b3
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
Version: 3.6.3~git20240930.c00f2a8-1
Version: 3.6+svn162-6
Version: 3.6+svn162-6+b1
Version: 3.7.0+git20240706-1+b1
Version: 3.9~git20240323.74d54fc-1+b4
Version: 4.004+git20190612-2
Version: 4.0.0+git20211227.5af5945b-2
Version: 4.0.0~git20221204.b897975-1
Version: 4.0.0+svn18614-1
Version: 4.0+git20190508.81d064c-4
Version: 4.0+git20200511.91cecb5+dfsg-1
Version: 4.13.0+git83-g91970fe-1
Version: 4.17.8~git20230417213433.6dab069+ds1-3
Version: 4.1+git200714-1
Version: 4~20181115+git4793b074-2
Version: 4.2.29.dev-1
Version: 4.3.0+git20221007.a3a1cc6-3
Version: 4.3.0+git20221007.a3a1cc6-3+b6
Version: 4.3.1~git20240304.46037e5-1
Version: 4.3.1+git20240409+ds-2
Version: 4.3.1+git20240409+ds-2+b1
Version: 4.4+git171022-2
Version: 4.4+git20170824+ds-1
Version: 4.504+git20201211-4
Version: 4.5.1+git230720-5
Version: 4.6+git20220505-1
Version: 4.9.12~4.17.8~git20230417213433.6dab069+ds1-3
Version: 4~git20230906.795fba0-2
Version: 4+svn20090216-4+b1
Version: 5.0.0+git23.g335dbec-6+b4
Version: 5.01.9674+git20200806+8181039+dfsg3-1
Version: 5.0.2+git20231211.1364ae4-7
Version: 5.0.2+git20231211.1364ae4-7+b2
Version: 5.0.3+git20151221.80e144e+dfsg-5+b3
Version: 5.0.6+git20211217+ds-4
Version: 5.0~git20180903.a14bd0b-6
Version: 5.0~git20180903.a14bd0b-6+b1
Version: 5.0~git20201102.f9a8f0fc+dfsg1-5
Version: 5.0~git20201102.f9a8f0fc+dfsg1-5+b1
Version: 5.0~git20230712.81e08ee+dfsg-3+b1
Version: 5.0+svn11846-10
Version: 5.1.0+git20150707-11
Version: 5.1.0+git20150707-11+b1
Version: 5.1.2+git20221018.fdd53fe-1.1
Version: 6.0.0+git20200210.224cad8-2
Version: 6.0+git20231212.4510c28+dfsg-3+b2
Version: 6.0+git20231212.5a852ed-2
Version: 6.2.0+git20240207-1+b1
Version: 6401+svn158-1.1
Version: 7.0.0+git20200316.f0a03a4b-1+b6
Version: 7.3.3+dfsg1-1+0.0~git20240826.db34745+dfsg-2
Version: 7.8.git20221117.28daf24+dfsg-8
Version: 7+svn20110807-5
Version: 8.1.3+git20180702~ds1-3+b2
Version: 8.2.0~next.0~1.0.0~git20230424.1320922-3
Version: 8.61+git20231015.c8ad982-6
Version: 9.0.0+git20221119-2
Version: 9.0.0+git20240131.6081731+dfsg-2

For the record, I assume it's most popular because it's the default for
the uscan "pretty" attribute.

Thanks for sharing!

I still think it would be good for the policy to be normative on this
to steer people into using the same format instead of coming up with
their own schemes.

control: reassign -1 src:developers-reference
thanks

which is defacto true.

also I agree with everything else Sean wrote in this bug.

you can still do this, whether it's in Policy, devref or neither. (just the
nudging level will vary.)

IMO defref is the perfect fit, because Policy should define what version
strings are "legal", while devref should recommend best practices.

Patch or commit much welcome! :)

control: reassign -1 developers-reference

Hello,

devref and Policy are both normative, just about different things, and
in different ways.

You can already go ahead and write a Lintian check for it.  It doesn't
need to be in devref or Policy or anywhere else.

You haven't made the case for this being in Policy as opposed to devref.

... or alternatively, following the feedback on this bug report, ask devscript to
change "pretty" not to include the %h part ?

But in general policy should refrain to be normative when there is no sound
technical reason. Popularity is not sufficient.  One could even argue that
there are more technical reasons not to include the hash.

Cheers,

bugs, patches & commits very welcome there too!

(with my very recent devscripts maintainer hat :)

^^^^^ that. Thanks for *that*! I will try to keep this in mind. (It's new, so.)

:)

I prefer to keep the version number as simple as possible.

Therefore, I used the format 0~20200916-1 for fonts-noto-color-emoji
(before it later adopted regular versioned releases). That format is
not detected by your grep command. This is similar to the format Simon
is using except that in my usecases, I didn't see a need to mention
the git commit hash. Unless I am in a rare hurry, I simply use the
final commit of the day.

I have a hard time seeing why 0.0~ should be preferred over 0~

Thank you,
Jeremy Bícha

same here.

I agree 0~20200916-1 is a perfectly fine version, and probably the most
recommendable one, as it's the simplest (in this setting).

same here.

thanks.

snapshots in general, and not only for "no releases" upstreams?

Something like:

In case you are packaging a snapshot or your upstream does not use
version numbers, the Debian package version will look like this:

<upstream-ver><snapshot-id>-1

where <upstream-ver> is:

* `<last-upstream-ver>+` if the version number of the upcoming upstream
release is not yet known;
* `<next-upstream-ver>~` if the version number of the upcoming upstream
release is already known;
* `0~` if this upstream has not done a release yet.

and <snapshot-id> is:

<git|svn|hg><yyyymmdd>.<last-commit-hash>

PS: I wouldn't mind having the commit hash in the version number, but in
that case it should be in a format (mostly) compatible with `git show`,
i.e. the commit hash should be prefixed by `-g`.

Regards,

With that explanation, I really think this should be a devref bug, not
a Policy bug. (Don't forget "Policy isn't a stick to beat people with".)

While it is nice to have a common ways, (e.g to reduce complexity
costs), not having a unique versioning scheme does not break something;
it just introduced work on people that have their (equally fine)
scheme... And, yeah to defining a best-practice. So let's reassign to devref?

Jeremy Bícha <jeremy.bicha@canonical.com> writes:

Re-reading

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version

I wonder if we couldn't make an argument that "upstream_version" is
empty, which actually better reflect that there is no upstream version
number instead of incorrectly claiming that upstream_version is "0".

I don't want to destroy consensus on 0~20200916-1, which is my
preference, but maybe a version string like ~20200916-1 works for the
no-upstream-version scenario.

/Simon