kicad-developers team mailing list archive
Mailing list archive
Re: 5.0.1 release
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 . 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
> > 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.