Re: [Kicad-developers] Minor releases (post v5.0.0)
I think this is relevant now so the feature set can be frozen definitely, but also don't make people feel like they either have to rush it now or wait years for their pet feature to appear on the next stable release, this could also mean dropping unfinished features in the interest of having v5 out the door on schedule, knowing that they will be there when ready in the next release. On Thu, Jan 11, 2018 at 12:41 PM, Wayne Stambaughwrote: > Please save this for the post v5 discussion. > > On 1/11/2018 1:27 PM, Chris Pavlina wrote: > > I agree with all of this 100%. > > > > On Thu, Jan 11, 2018 at 11:45:58AM -0600, José Ignacio wrote: > >> I've started to see a flurry of features that are either getting rushed > in > >> for v5.0 or being pushed aside to the future "v6" version of kicad. Due > to > >> the limited resources of the development team and the sheer amount of > work > >> for each major release, the development cycles get pretty long, and many > >> small but significant features will not see wide use until v6 will come > out > >> in a couple of years, as new features are not allowed in bugfix > releases. > >> > >> Would it be possible to this week clamp down completely now on _any_ > kind > >> of new feature for v5.0, and instead of pushing it to v6 (which sounds > very > >> far in the future), push it instead to v5.1, which could be released > just a > >> few months after v5.0 and include small features that don't break > >> compatibility in a major way. That should also ease the continual > >> backporting of bug fixes as the stable branch wont get overly stale, and > >> small convenience features will get much better testing before the rush > of > >> the next release. IMO it will make the 5->6.0 cycle a lot less stressful > >> than it's been for the past two cycles. > >> > >> Features in the v4->5 cycle that have forced me to use the master branch > >> for production are things like the eeschema field autoplacing, eeschema > >> field editor, gal performance improvements, STEP support. All things > that > >> didn't really break compatibility of my projects as much as a major > release > >> can do, but many people using the stable release haven't been able to > test. > >> > >> ~Jose > > > > > > ___ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Minor releases (post v5.0.0)
Please save this for the post v5 discussion. On 1/11/2018 1:27 PM, Chris Pavlina wrote: > I agree with all of this 100%. > > On Thu, Jan 11, 2018 at 11:45:58AM -0600, José Ignacio wrote: >> I've started to see a flurry of features that are either getting rushed in >> for v5.0 or being pushed aside to the future "v6" version of kicad. Due to >> the limited resources of the development team and the sheer amount of work >> for each major release, the development cycles get pretty long, and many >> small but significant features will not see wide use until v6 will come out >> in a couple of years, as new features are not allowed in bugfix releases. >> >> Would it be possible to this week clamp down completely now on _any_ kind >> of new feature for v5.0, and instead of pushing it to v6 (which sounds very >> far in the future), push it instead to v5.1, which could be released just a >> few months after v5.0 and include small features that don't break >> compatibility in a major way. That should also ease the continual >> backporting of bug fixes as the stable branch wont get overly stale, and >> small convenience features will get much better testing before the rush of >> the next release. IMO it will make the 5->6.0 cycle a lot less stressful >> than it's been for the past two cycles. >> >> Features in the v4->5 cycle that have forced me to use the master branch >> for production are things like the eeschema field autoplacing, eeschema >> field editor, gal performance improvements, STEP support. All things that >> didn't really break compatibility of my projects as much as a major release >> can do, but many people using the stable release haven't been able to test. >> >> ~Jose > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Minor releases (post v5.0.0)
I agree with all of this 100%. On Thu, Jan 11, 2018 at 11:45:58AM -0600, José Ignacio wrote: > I've started to see a flurry of features that are either getting rushed in > for v5.0 or being pushed aside to the future "v6" version of kicad. Due to > the limited resources of the development team and the sheer amount of work > for each major release, the development cycles get pretty long, and many > small but significant features will not see wide use until v6 will come out > in a couple of years, as new features are not allowed in bugfix releases. > > Would it be possible to this week clamp down completely now on _any_ kind > of new feature for v5.0, and instead of pushing it to v6 (which sounds very > far in the future), push it instead to v5.1, which could be released just a > few months after v5.0 and include small features that don't break > compatibility in a major way. That should also ease the continual > backporting of bug fixes as the stable branch wont get overly stale, and > small convenience features will get much better testing before the rush of > the next release. IMO it will make the 5->6.0 cycle a lot less stressful > than it's been for the past two cycles. > > Features in the v4->5 cycle that have forced me to use the master branch > for production are things like the eeschema field autoplacing, eeschema > field editor, gal performance improvements, STEP support. All things that > didn't really break compatibility of my projects as much as a major release > can do, but many people using the stable release haven't been able to test. > > ~Jose ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Minor releases (post v5.0.0)
I've started to see a flurry of features that are either getting rushed in for v5.0 or being pushed aside to the future "v6" version of kicad. Due to the limited resources of the development team and the sheer amount of work for each major release, the development cycles get pretty long, and many small but significant features will not see wide use until v6 will come out in a couple of years, as new features are not allowed in bugfix releases. Would it be possible to this week clamp down completely now on _any_ kind of new feature for v5.0, and instead of pushing it to v6 (which sounds very far in the future), push it instead to v5.1, which could be released just a few months after v5.0 and include small features that don't break compatibility in a major way. That should also ease the continual backporting of bug fixes as the stable branch wont get overly stale, and small convenience features will get much better testing before the rush of the next release. IMO it will make the 5->6.0 cycle a lot less stressful than it's been for the past two cycles. Features in the v4->5 cycle that have forced me to use the master branch for production are things like the eeschema field autoplacing, eeschema field editor, gal performance improvements, STEP support. All things that didn't really break compatibility of my projects as much as a major release can do, but many people using the stable release haven't been able to test. ~Jose ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp