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
