kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

On Mon, Oct 20, 2014 at 8:58 AM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
wrote:

> In the past we have used the repo commit number as the stable version
> number.  I'm not sure this is the best idea as there can be overlapping
> commit numbers in separate branches.  I would like to propose using
> something that we can clearly identify as a release version to prevent
> confusion due to duplicate commit version numbers.  I recently committed
> the stable release policy to the developers documentation but I
> intentionally left out the version number section because I wanted to
> make sure we are on board with the idea.  It would make it clear to
> developers, users and packagers that they are using a stable release
> versus a development release.  It also makes it easier to name source
> and binary packages.  I'm perfectly happy using the good old fashioned
> numerical triplet (#.#.#).  It's easy for most version comparison
> functions to deal with.  I suggest for the next stable release we start
> at the beginning 1.0.0.  If no one objects, I will update the stable
> release policy and add the code to CMakeLists.txt before we get to the
> next stable release.
>
> Thanks,
>
> Wayne
>

I'm not in favor of 1.0.0 because this suggests that this is the first
release after Beta.
KiCad has a much longer history of  productive use.  I think at least 2.1.x
- 2 because
this is very different from what many Linux distributions consider as the
last KiCad
stable (old pcb format) and .1 because there has also been a revision of
the new
pcb file format to support 32 copper + 32 tech layers. I don't really have
any strong
preference for the '.1' part, but we definitely need at least '2' for the
major version;
humans are funny creatures and tend to associate version 1 with an inferior
product.

- Cirilo