kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Here is the stable release policy:

http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_stable-release-policy.html

I still need to add the numbering system to this.

On 2/24/2015 11:00 AM, Adam Wolf wrote:
> Hi folks,
> 
> I have started and deleted this email multiple times.  I really don't
> enjoy discussions like this, but sometimes they're necessary.
> 
> I have ran into quite a few misconceptions recently from non-devs about
> what the upcoming release is going to be.  The issues I am seeing seem
> to hinge around the word "stable".
> 
> As far as I know, every single source commit we make, we intend to be
> stable and usable, and we don't really commit half-features very often
> (if ever), and I have been seeing users get very confused about that
> based on the word "stable" for the upcoming release.

This will always be a goal for the product branch as long as I am
project leader.  Keeping the development branch usable is important.

> 
> As far as I know, there are going to be two things that make the
> upcoming release "special":
> 
> 1) a feature freeze beforehand so we can run manual tests, make sure our
> features work well, and hopefully fix any packaging issues on the main
> targets without any churn of new features
> 
> 2) file format incompatibilities

3) A bunch of new features (gal, pns router, 64 layers, etc.) since the
last "stable" release.

> 
> What about instead of calling it "stable", we called it by a version
> number?  Kicad 2.0?  I think more users would understand what we're doing.

We discussed using a triplett.  Most likely the upcoming release will be
3.0.0 or 4.0.0.  Either is fine by me.  There will never be a 3.1.X or
3.2.X because features will *not* be back ported under the current
policy.  Only critical errors (read crash, data loss, memory leaks, etc)
will be fixed in the stable release branch so there will only be 3.0.1,
3.0.2, etc, versions.  There will be no attempt to maintain
compatibility with the development branch file formats.  Either you
bleed on the edge and help with testing or you live with the features in
the current stable release.  I am not reopening this subject for
discussion for obvious reasons.  We've beat this horse to death and
given our resource limitations, this is the best compromise.

> 
> This email is primarily directed at Wayne, but I like to keep things in
> the open if possible.
> 
> Adam Wolf
> Cofounder and Engineer
> Wayne and Layne
> 
> 
> _______________________________________________
> 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
>