Re: version format for git snapshot
On Tue, Sep 15, 2015 at 1:24 AM, Colin Watson wrote: > > This is what I generally do: last release + "git" + ISO 8601 date and > time > > + 10-char substring of the commit id. I. e: > > > > 0.5+git20150531T211420-cdd9d98f2c-1 > > IME it is in fact useful to have version numbers that stand a chance of > fitting in people's short-term memory. > > That's definitely an advantage of your schema over my schema. The idea of having the commit id in the version string was to make versions (easily) machine processable. But if one is not going to release more than one snapshot a day (and I guess very few people do -- I rarely do!), then it's something to consider, definitely. Hmmm I'll have to think what to do next time I'm going to package snapshots! :-) Thank you for sharing! -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: version format for git snapshot
On Mon, Sep 14, 2015 at 10:46:10AM +0200, Pau Garcia i Quiles wrote: > On Mon, Sep 14, 2015 at 8:51 AM, Colin Watson wrote: > > I wouldn't put the commit identifier in the package version at all. It > > isn't sortable, so clearly doesn't belong in a version string; it can be > > documented in the changelog instead. I'd put a date in the version. > > The problem with date is searching in git log is difficult. You can still add the commit ID to the changelog as plain text for your later convenience when searching git log. That doesn't imply putting it in the version string, which (depending on how it's done) is either a non-sortable obstacle or simply cruft. Version numbers don't need to contain essays on the provenance of the code. > This is what I generally do: last release + "git" + ISO 8601 date and time > + 10-char substring of the commit id. I. e: > > 0.5+git20150531T211420-cdd9d98f2c-1 IME it is in fact useful to have version numbers that stand a chance of fitting in people's short-term memory. -- Colin Watson [cjwat...@debian.org]
Re: version format for git snapshot
Quoting Pau Garcia i Quiles (2015-09-14 12:23:57) > > On Monday, September 14, 2015, Jonas Smedegaard wrote: >> Makes perfect sense to me to add only the date for snapshot releases >> - both revision control system and commit id is irrelevant in version >> string - those belong (if at all) in changelog along with release >> nickname and whether release coincided with your birthday. >> >> I will use this scheme from now on: >> >> 0.4+20150911 > > What if you take a second snapshot on that day? 0.4+20150911.1 - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: version format for git snapshot
On 2015-09-14 at 05:04, Jakub Wilk wrote: > * Pau Garcia i Quiles , 2015-09-14, 10:46: > >> 0.5+git20150531T211420-cdd9d98f2c-1~vivid~pgquiles1 > > Still shorter than > 1.31~pre0.8052aabdd159bc9050e7dc264f33782c5acce05f-1. You're not > trying hard enough. I am reminded of this entry from the fortunes database: * In anticipation of 2.10.02 release, updated to patchlevel +ircu2.10.01+.config6-7.config7-8.lgline3.iwho.limit.glibc.motdcache2.trace.whois1-2.config8-9.statsw.sprintf2-3.msgtree2.memleak1-2+.msgtree2-3.gline8-9.gline9-10.invite2.rbr.stats.numclients.whisper.whisper1-2.stats1-2.nokick1-2.chroot.config9-11.snomask7-8.limi+t1-3.userip1-3.userip3-4.config11-12.config12-13.umode2-3.akillsbt.who4-5.kn.kn1-2.freebsdcore2.msgtree3-5.y2k.glibc1-2.rmfunc.msgf+lags2.who5-6.nickchange2.glibc2-3.modeless3 -- From the annoucement of ircd 2.10.01-3 for Debian GNU/Linux -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Re: version format for git snapshot
On Mon, 14 Sep 2015 07:51:09 +0200 Thomas Koch wrote: > Hi, > > my upstream tagged 0.4 a year ago and I want to package the current > master commit a5e5f9e that is 24 commits after 0.4. Please assume > that this makes sense... > > How would you format the upstream part of the packages version > number? How about 0.4+24+git+a5e5f9e? > > The git describe output is v0.4-24-ga5e5f9e. > > Is there any established best practice? One of the steps I use is to look at the rev-list to get a sequential number which is based on the actual commits but is in a sane sequence. https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/version.py git rev-list --count HEAD These are local developer builds, not usually released, but still - could be useful for someone. As well as sticking the short hash in the changelog entry, we also append it to the version. ava-dispatcher 2015.9.3908.875bd74-1 amd64 The rev-list takes care of the hash not being a reliable sort as the hash is effectively hidden from the sort algorithm. It's added because it's a simple way of looking up the commit on gitolite etc. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpRg2XdPKY57.pgp Description: OpenPGP digital signature
Re: version format for git snapshot
On Monday, September 14, 2015, Jonas Smedegaard wrote: Makes perfect sense to me to add only the date for snapshot releases - > both revision control system and commit id is irrelevant in version > string - those belong (if at all) in changelog along with release > nickname and whether release coincided with your birthday. > > I will use this scheme from now on: > > 0.4+20150911 > > What if you take a second snapshot on that day? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: version format for git snapshot
Quoting Colin Watson (2015-09-14 08:51:48) > On Mon, Sep 14, 2015 at 07:51:09AM +0200, Thomas Koch wrote: >> How would you format the upstream part of the packages version >> number? How about 0.4+24+git+a5e5f9e? > > I wouldn't put the commit identifier in the package version at all. > It isn't sortable, so clearly doesn't belong in a version string; it > can be documented in the changelog instead. I'd put a date in the > version. Makes perfect sense to me to add only the date for snapshot releases - both revision control system and commit id is irrelevant in version string - those belong (if at all) in changelog along with release nickname and whether release coincided with your birthday. I will use this scheme from now on: 0.4+20150911 - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: version format for git snapshot
On Mon, Sep 14, 2015 at 11:04 AM, Jakub Wilk wrote: * Pau Garcia i Quiles , 2015-09-14, 10:46: > >> 0.5+git20150531T211420-cdd9d98f2c-1~vivid~pgquiles1 >> > > Still shorter than 1.31~pre0.8052aabdd159bc9050e7dc264f33782c5acce05f-1. > You're not trying hard enough. Oh well, I'm just trying to get all the required information with minimal verboseness :-) You don't need the full commit id, 10 chars is usually more than enough in a repository -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: version format for git snapshot
* Pau Garcia i Quiles , 2015-09-14, 10:46: 0.5+git20150531T211420-cdd9d98f2c-1~vivid~pgquiles1 Still shorter than 1.31~pre0.8052aabdd159bc9050e7dc264f33782c5acce05f-1. You're not trying hard enough. -- Jakub Wilk
Re: version format for git snapshot
On Mon, Sep 14, 2015 at 8:51 AM, Colin Watson wrote:
On Mon, Sep 14, 2015 at 07:51:09AM +0200, Thomas Koch wrote:
> > How would you format the upstream part of the packages version number?
> How
> > about 0.4+24+git+a5e5f9e?
>
> I wouldn't put the commit identifier in the package version at all. It
> isn't sortable, so clearly doesn't belong in a version string; it can be
> documented in the changelog instead. I'd put a date in the version.
>
The problem with date is searching in git log is difficult.
This is what I generally do: last release + "git" + ISO 8601 date and time
+ 10-char substring of the commit id. I. e:
0.5+git20150531T211420-cdd9d98f2c-1
It includes all the information:
- Last release (0.5)
- It's screaming "I'm a git snapshot!" ("git")
- It's sortable thanks to the ISO 8601 date *and* time (20150531T211420)
- Commit id, for easier search in git log, git describe, etc (cdd9d98f2c)
- Debian packaging version (1)
- It's consistent: it's always the same regex, with no room for optional
fields
Using the time is required, otherwise if there are two snapshots in one
day, they may get the wrong sorting order due to the git commit id.
Do you think it's ugly? Wait to see what it gets to when I upload packages
to my Ubuntu PPA :-)
0.5+git20150531T211420-cdd9d98f2c-1~vivid~pgquiles1
IMHO it'd be great if we could standardize on something, not matter what it
is.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Re: version format for git snapshot
Hello Thomas Koch! On Mon, Sep 14, 2015 at 07:51:09AM +0200, Thomas Koch wrote: > Hi, > > my upstream tagged 0.4 a year ago and I want to package the current master > commit a5e5f9e that is 24 commits after 0.4. Please assume that this makes > sense... > > How would you format the upstream part of the packages version number? How > about 0.4+24+git+a5e5f9e? > > The git describe output is v0.4-24-ga5e5f9e. > > Is there any established best practice? I see there are already multiple suggestions, so here's yet another color suggestion for the bikeshed... The below mentioned format is understood by /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk which will download (or in this case generate) the orig tarball on fakeroot debian/rules get-orig-source for all pkg-gnome packages. (But ofcourse, even though there are alot of packages supporting this format we rarely do git snapshots so you won't find many of them in the archive currently.) # search for a GIT revision in the version of the changelog # accepted formats: foo+git20090430.42ad43 (or ~ instead of +) DEB_UPSTREAM_GIT_REV ?= $(shell echo $(DEB_UPSTREAM_VERSION) | sed -rn 's/^.*[\.~+\d]+git[0-9]+\.([0-9a-f]+)$$/\1/p') In my opinion this formatting is good, simple and reasonably short (compared to similar suggestions). Regards, Andreas Henriksson
Re: version format for git snapshot
On 09/14/2015 07:51 AM, Thomas Koch wrote: > Hi, > > my upstream tagged 0.4 a year ago and I want to package the current master > commit a5e5f9e that is 24 commits after 0.4. Please assume that this makes > sense... > > How would you format the upstream part of the packages version number? How > about 0.4+24+git+a5e5f9e? > > The git describe output is v0.4-24-ga5e5f9e. > > Is there any established best practice? > > Have a nice week, > > Thomas Koch git describe is your friend indeed! :) What I do may be a bit over-engineered: 1.2.3+2015.06.16.git26.9634b76ba5 which of course is: upstream.release+date.gitnumcommits.sha256 It'd be nice if we could all do the same thing. Not saying that my version is the best (I wouldn't mind changing for another format), but having standards is good. Cheers, Thomas Goirand (zigo)
Re: version format for git snapshot
On Mon, Sep 14, 2015 at 07:51:09AM +0200, Thomas Koch wrote: > How would you format the upstream part of the packages version number? How > about 0.4+24+git+a5e5f9e? I wouldn't put the commit identifier in the package version at all. It isn't sortable, so clearly doesn't belong in a version string; it can be documented in the changelog instead. I'd put a date in the version. -- Colin Watson [cjwat...@debian.org]
Re: version format for git snapshot
Hi Thomas, Quoting Thomas Koch (2015-09-14 07:51:09) > my upstream tagged 0.4 a year ago and I want to package the current > master commit a5e5f9e that is 24 commits after 0.4. Please assume that > this makes sense... > > How would you format the upstream part of the packages version number? > How about 0.4+24+git+a5e5f9e? > > The git describe output is v0.4-24-ga5e5f9e. > > Is there any established best practice? I'd use a single "+", mention revision control system first, and include date¹ of latest commit in snapshot (rather than number of commits from release - another later snapshot may not be linear progress but from another shorter branch, and therefore a lower number). And then I'd use only 7 digits of hash as that's common short-form in git. Therefore, I'd use this: 0.4+git20150911~ga5e5f9 - Jonas ¹ In the rare event of making more snapshots same day I'd add a counter for my clumsiness - i.e. 0.4+git20150911.1~ga5e5f9 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: version format for git snapshot
Hallo, * Thomas Koch [Mon, Sep 14 2015, 07:51:09AM]: > Hi, > > my upstream tagged 0.4 a year ago and I want to package the current master > commit a5e5f9e that is 24 commits after 0.4. Please assume that this makes > sense... > > How would you format the upstream part of the packages version number? How > about 0.4+24+git+a5e5f9e? > > The git describe output is v0.4-24-ga5e5f9e. Is -24 a part of upstream version? I used to incorporate the date... 0.4-24+git+20150914+ga5e5f9e-1 (and you can still add a modifier to the date if you need another snapshot). > Is there any established best practice? > > Have a nice week, Yoo too... Eduard.
version format for git snapshot
Hi, my upstream tagged 0.4 a year ago and I want to package the current master commit a5e5f9e that is 24 commits after 0.4. Please assume that this makes sense... How would you format the upstream part of the packages version number? How about 0.4+24+git+a5e5f9e? The git describe output is v0.4-24-ga5e5f9e. Is there any established best practice? Have a nice week, Thomas Koch
