On Thu, 2010-10-07 at 06:05 -0700, Arjan van de Ven wrote: > On 10/7/2010 5:57 AM, Andrew Wafaa wrote: > > On Thu, 2010-10-07 at 13:43 +0100, Ross Burton wrote: > >> Is there a best-practise for versioning a git snapshot? > >> > >> At the moment I'm working towards something like: > >> > >> [new release number]~[commit count].g[commit hash abbrev] > >> > >> (inspired by git-describe HEAD) > >> > >> So if we'd packaged 0.1, then a git snap would be 0.2~42.g123456. > >> > >> Ross > >> _______________________________________________ > >> MeeGo-packaging mailing list > >> [email protected] > >> http://lists.meego.com/listinfo/meego-packaging > > I'm no expert but... > > > > Using your example, I would recommend you don't use the full new version > > number as it will conflict with the actual final release. > > > > So using your example I would say use: > > > > 0.1.99_42.g123456 > > > > Or use the date in there somewhere. > > > > Also something to keep in mind is that when packaging there are certain > > charachters in file names that can cause issues, I forget exactly what > > they all are, but I'm sure ~ is one of them. > > ~ is actually specifically recommended to be used; it's the RPM (in > MeeGo RPM at least) separator for > "this ranks lower in sorting than anything without a ~" > > that's why Ross' example is actually the right one and he does not need > to do the 0.1.99 weirdness.
They will both work, but since git hashes are not ordered, its just a question of whether that is desired with [commit-counts] inserted into the version number. rpmlint complaints can be ignored. Following git-describe would be nice, It is a pain to construct release~githash versions by hand vs `git describe`. > _______________________________________________ > MeeGo-packaging mailing list > [email protected] > http://lists.meego.com/listinfo/meego-packaging _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
