kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 7/9/19 4:49 PM, Carsten Schoenert wrote:
> Hello Nick,
> 
> Am 09.07.19 um 21:57 schrieb Nick Østergaard:
>> I have a hard time to understand how  5.99 is better to describe a 
>> development version. 6.00 was already a bad way to describe it.
>> People also were confused. To me .99 seems very arbitrary. Why not
>> .1234?
> simply your mind is interpreting this different than .99. ;)
> 
> GTK+ is doing this scheme with .90 to .99 for quite a while and this is
> *oneway* to do it.
> 
> https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/
> 
> KiCad is not the first project that needs to find it's own agreement on
> the versioning. (And wont be the last.)
> 
> I'm personally not that happy with the usage of the 'git describe'
> command and the reading of tags from the tree. It was never a good
> approach in my eyes and it is currently really horrible for users to
> interpret the numbering schema. Even the current HEAD on the stable
> branch has a wrong number starting with.

I want to keep the sha hash so we know which commit was used to create
nightly builds.  While `git describe` isn't perfect, it does a pretty
good job of giving us the information we need.

> 
> Why not hard-code the prefix within the CMake scripting voodoo like done
> in probably the majority of recent project that using autotools for
> configuration and add the commit count and id as a suffix like done now
> already?

We do this in KiCadVersion.cmake but this is only used as a fallback
when git isn't available during config.

> 
> And a prefix '6.0-dev' or 'master-dev' is always better than the current
> solution.
> 

We abandoned the "-dev" suffix because package devs were complaining
that "6.0-dev" was causing packaging version comparison issues.  If that
is not the case, then we need to get a consensus among the package devs
for a solution that works for all platform package managers.  I'm
guessing the ".99" (or some other sufficiently large number) would work
and also make it clear to users that they are using a version newer than
the current stable version.

In short, we need a solution that

a: solves the packaging version comparison issue on all platforms

b: makes it clear to users that they are using a version greater than
the current stable release

c: provides the needed developer information on nightly builds

Am I missing anything here?