kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

The current stable release policy can be found here:

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

I have no intention of changing it for the upcoming stable release.
This policy is based on the limited amount of manpower which I don't see
changing any time soon.  Things are improving but we still have a long
way to go until I'm willing to commit resources to a more comprehensive
release schedule.

On 9/11/2015 5:00 PM, timofonic timofonic wrote:
> I have a naive idea...
> 
> What about release the stable branch when all bugs and other issues
> (performance?) get resolved and then keep these changes to another
> release with smaller but useful changes?
> 
> I believe this can give many advantages:
> 
> - Finally a STABLE version gets released after many years. Please avoid
> excessive delays, even if that means a bugfix release. Better soon with
> some to polish later than delay it and waste the newly gained interest
> in KiCad.
> 
> - Minor versions could be nice gifts and keep attention span from users,
> developers and media.
> 
> On Sep 11, 2015 8:02 PM, "Wayne Stambaugh" <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>> wrote:
> 
>     Joseph,
> 
>     I've already made the call for no new features.  If I allow this change
>     then that opens the flood gates for everyone else to ask for an
>     exception.  We are so far behind were I would like to be on the stable
>     release that I do not want to jeopardize things any longer.  Please keep
>     this in a separate branch so it's ready to be merged into the product
>     branch as soon as the stable release is complete.  I appreciate you
>     understanding regarding this decision.  Also, please keep in mind that
>     we make every effort to keep the product branch as stable as possible so
>     that developers and users are willing to keep testing it.
> 
>     Cheers,
> 
>     Wayne
> 
>     On 9/11/2015 3:58 AM, Joseph Chen wrote:
>     > @JP and @Wayne,
>     >
>     > Would you take a patch for fixing this ERC's not detecting local
>     labels?
>     > I know we were reminded not to, but I believe this fix should be
>     in the
>     > stable release.  See my explanation below.
>     >
>     > On 09/01/2015 12:09 AM, jp charras wrote:
>     >> Le 01/09/2015 04:59, Joseph Chen a écrit :
>     >>> On 08/31/2015 05:10 AM, jp charras wrote:
>     >>>> Le 28/08/2015 04:54, Joseph Chen a écrit :
>     >>>>> This is a resubmitting of a patch file (attached)  that fixes the
>     >>>>> issue
>     >>>>> of [Bug 1487945].  This time it it more coding style compliant as
>     >>>>> suggested in other developer's comments.
>     >>>>>
>     >>>>> The fix passed tests on Ubuntu 15.04, based off KiCAD BZR 6133
>     >>>>>
>     >>>>> --Joe
>     >>>> Committed. Thanks.
>     >>> Thank you JP!  I am now working on enabling ERC to catch errors of
>     >>> unmatched LOCAL labels as well.
>     >>>
>     >>> --Joe
>     >>>
>     >> Unmatched LOCAL labels are a frequent case: they can just name a
>     >> connection to help routing, create schematic documentation, or
>     can just
>     >> act as a comment in schematics+boards (I am widely use them).
>     >>
>     >> Unmatched LOCAL labels are in many cases not an error.
>     >> Detecting them can be useful, but this detection have to be
>     >> enabled/disabled on option.
>     > In my local working branch, I was able to make this ERC's detecting
>     > unmatched local labels work as suggested by JP:
>     > Within the ERC pop-up dialog window, there is an added extra check box
>     > for detecting unmatched local labels.  By default, the check box is
>     > "un-checked". When a user clicks to enable it, the ERC is able to
>     report
>     > any and all unmatched local labels.
>     >
>     > Here is why I think this ERC's detecting unmatched local labels is
>     > essential:
>     >
>     > 1. At work, I am using OrCAD Capture for schematic, and I always use
>     > OrCAD's local labels as the netlists for track connections, as do
>     other
>     > designers in the team.
>     >
>     > 2. At home, then, when working on my hobby projects, I am using KiCAD
>     > with the same habit and discipline of using the local labels for intra
>     > sheet netlists.
>     >
>     > 3. When these local labels are either misspelled or forgotten at some
>     > other ends of the parts, they become unmatched and thus result in
>     single
>     > netlist names.
>     > 4. When current KiCAD does not detect these unmatched local
>     labels, here
>     > is a sure worst scenario: the PCB made with this unmatched local
>     labels
>     > will not have the intended ratnets and thus no copper tracks will be
>     > laid out.  Ultimately it is rendered a non working PCB.
>     >
>     > Let me know if you have any questions,
>     >
>     > --Joe
>     >
>     >
>     > _______________________________________________
>     > Mailing list: https://launchpad.net/~kicad-developers
>     > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     > Unsubscribe : https://launchpad.net/~kicad-developers
>     > More help   : https://help.launchpad.net/ListHelp
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers
>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
>