kicad-developers team mailing list archive

[Joseph Chen <joseph.chen59@xxxxxxxxx>]

On 11/27/2016 11:44 PM, Nick Østergaard wrote:
> 2016-11-28 0:01 GMT+01:00 Joseph Chen <joseph.chen59@xxxxxxxxx>:
> > As I see it, KiCAD now is using a backward schema in versioning, after
> > converted to GIT repo.
> >
> > As most of you guys already know it, GIT has a command "git describe
> > --dirty" for outputting a precise trackable version info.  So regardless of
> > branches, the version string should be set by the output of this GIT
> > command.  (I was a seasonal Linux kernel driver contributor over 10 years
> > ago and Linux kernel has been using this way for versioning).
> >
> > Here is an example:
> > 1. Withi my current running Kicad, cliking "Help-->About Kicad",  it
> > produces
> >       "Version: (2016-11-10 revision 3184295)-master, release build"
> > Which is not trackable at all.  If I filed a bug report with this version
> > info, you would definitely be unable to pinpoint to a exact source set in
> > the repo.
> >
> > 2.  In contrast, invoking the GIT command in the source repo produces:
> > jchen@thermaltake ~/git-kicad/kicad (master)
> > $ git describe --dirty
> > 4.0.0-rc2-1622-g3184295
> > jchen@thermaltake ~/git-kicad/kicad (master)
> >
> > As you can see, it says the current version has been committed "1622" times
> > after tag "4.0.0.rc2", and the git commit SHA1 signature is "3184295".
> >
> > Hope this makes sense to you guys.
> >
> > --Joe Chen
> That is all fine, but that is not the real issue here. The issue is
> how to get a version from the tarball release. One could argue that we
> should just stop using tarballs and packagers should use git directly.
> That could posisbly work, but the problem may still arise if packagers
> use the repository web viewer tool to get a tarball from the tag. Then
> the question still becomes; how do we make sure there are a sane
> version when there is no git to help us.
Aha, thanks.  Now I know what the issue is.

This is a common issue to developers that are using git repos.  The good 
news: there is a work flow to solve this exact issue (I had learned many 
many years ago and been using at work daily).

Here are brief steps of the work flow:

===To Generate the Tarball:
0. Change to the top of the repo directory
1. Invoke command "git describe --dirty > version.txt".
2. Invoke command "git archive" to generate a tarball or zip ball (needs 
more parameters to get the chosen format)
3. Append the generated file "version.txt" to the generated tarball.  
(GNU tar can do this.)

The above steps can be wrapped in a script file to be used as a hook for 
Web interface.

== To Build with CMAKE, or any mak:
0. Change to the top of source directory (can be either of the untar'ed 
source or a git repo source)
1. Invoke command "git describe --dirty".
2. If command in Step 1 succeeded, using the output of the command as 
the version string (now you know it's a repo source); Otherwise, using 
the line from file "version.txt" as the version string (now you know 
it's a tarball source).

After all, any packager can append anything she or he wants to the 
version string.

Hope this helps,

--Joe Chen