← Back to team overview

kicad-developers team mailing list archive

Re: 5.0.1 release


Hi Carsten-

Am Mi., 29. Aug. 2018 um 22:38 Uhr schrieb Carsten Schoenert <

> Hello Seth,
> Am 29.08.18 um 22:32 schrieb Seth Hillbrand:
> > Hi All-
> >
> > Quick question for packagers:  If we need to re-make a package after
> > 5.0.1 is released, can we use -DKICAD_VERSION_EXTRA=1 when you re-build
> > and increment the number for each subsequent build of the same release?
> I'm not sure what you mean by 'If we need to re-make'.

The case I envision is if a package is accidentally built using the wrong
flags and needs to be re-built using the same software source.

> KiCad uses until
> now the semantic versioning [1]. At least what I think about the version
> number. So I my understanding is simply you will increase the PATCH
> version with every fixup release like done in the past. If you create a
> new micro version the version string is simply 'major.minor.patch+1'.

Correct!  This version string is my hope.  The KICAD_VERSION_EXTRA=1 define
will make it 'major.minor.patch-1' but I'm happy with packagers using
either.  I really just want to be able to tell from which packaging a bug
report originates.

> > The extra string will be appended to the KICAD_FULL_VERSION and get
> > reported in the bug reports version listing.  This would greatly help to
> > identify issues as well as give users the heads up when there is a newer
> > version that they should be using.
> All you need is an unequivocal version, right.

Yes.  I thought to give an example that would accomplish this but I'm very
happy with a different approach that achieves the same unequivocal version
number that includes build revision.  I do not intend for this to be
complicating and I'm very happy with any solution that gets to the same
result.  What I really hope to avoid is the version 5.0.0 situation where
our first step when debugging windows-based KiCad crashes is to ask users
to re-download the same version again.

Best Regards-