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" <[email protected] > <mailto:[email protected]>> 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 : [email protected] > <mailto:[email protected]> > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
