Hi Samuel, Julian and Marco Regarding >But I agree that the '.1.' is excessive (even though I have been > guilty of it myself - I was just copying what someone else had done > and presumed that it had a good reason...). The '.1.' helps to keep the version numbers monotonically increasing if there should be another version for the same date. For instance 1.2.3+git20200422.ef8a32b 1.2.3+git20200422.2193ffa is not monotonically increasing, but one enforces it this way 1.2.3+git20200422.1.ef8a32b 1.2.3+git20200422.2.2193ffa I agree you will really need this quite rarely. While the commit fingerprint is a must as it serves to uniquely identify a commit. @Samuel: If the teams prefers a different way to construct the version, I am happy to adopt this. Regards, Sven Am Mittwoch, den 22.04.2020, 16:55 +0100 schrieb Julian Gilbey: > On Wed, Apr 22, 2020 at 03:09:16PM +0200, Marcos Fouces wrote: > > Hi Julian and Samuel > > > > I found that there is 1493 binary packages that use the "git" > > string in > > the release number. There is some exotic variations (like this one > > 0.0~GOTK3~0~2~0+git20170418.0.96d4110-3) > > > > I believe that ".1." refered by Samuel could be considered as a > > kind of > > an epoch. This is useful because the characters of the commit > > cannot be > > used to sort releases. > > > > IMHO, there is no strong need to insert the date, some characters > > of > > commit id, a custom epoch... Using "git+date" should be enough in > > most > > cases. > > Hi Marcos, > > I have found that having a commit id in the package version can be > helpful: > > - sometimes there is more than one upstream commit in a day > > - sometimes the commit date is somewhat ambiguous, especially if the > commit was on a different branch and then merged into the master > branch at a later date - what is the date that should then be used? > Different maintainers have used different choices, but the commit > id > is unambiguous. > > These have arisen when I've been trying to compare a Debian package > to > the upstream original to track down some issue or other. > > But I agree that the '.1.' is excessive (even though I have been > guilty of it myself - I was just copying what someone else had done > and presumed that it had a good reason...). > > > If you add some more commits, you can add them as patches in > > d/patches > > and refer it in d/changelog. > > Or just release a new version? Or do you mean cherry-picking later > commits? > > Best wishes, > > Julian >
Attachment:
signature.asc
Description: This is a digitally signed message part