kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

d: keep it as is

e: prepend the branch to what we currently have

On Wed, 10 Jul 2019 at 17:55, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>
> 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?
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp