OK, the two patches are up. Cheers, Jeff.
> On 9 Feb 2018, at 14:27, Nick Østergaard <oe.n...@gmail.com> wrote: > > 2018-02-09 15:05 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com > <mailto:stambau...@gmail.com>>: > On 2/9/2018 1:34 AM, Carsten Schoenert wrote: > > Am 09.02.2018 um 01:54 schrieb Wayne Stambaugh: > >>> If you want to tag rc1 this weekend, should we tag the libs as well? > > > > Absolutely! Don't make the life of distributions and packagers more > > complicated than needed. > > I'm not sure how we want to go about this for libs, docs, and > translations. Simple tagging is easy enough but it is somewhat limited. > Tagging and branching is a far more complex task because now you have > to deal with back porting changes that are relevant to the stable > branch. I don't have a preference but then again I'm not maintaining > any of this so I don't feel I have any right to ask someone else to do > it. I know how much work it was to back port fixes to the stable 4 > branch. We need to decide what make the mosts sense and live with that > decision. Of course we can always do something different for the next > release if what we decide to do this time doesn't work out. > > Depending on who we want to use it we do not need to branch before it is > needed, if it is ever needed. The rc tags can be on master without issues. > Then the git describe output will also be more relevant. Remember branching > can be far back in time, so there is no rush performing the branching just > yet. > > > > > > There was a interesting talk on FOSDEM about how to make releases right > > (in terms of "No, please don't do it this way."), the content isn't new > > but sometimes it's good to look at this all from a sarcastic view. > > > > https://fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/ > > <https://fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/> > > I wanted to make it to this talk but there was a conflict with another > talk. Great talk. This was too funny! > > I've tried my best make kicad easy for package developers. There are > still some issues to resolve but I think we are in pretty good shape. > > > > >>> Should we limit changes to the lib from that point on until the final > >>> stable release or can we still make larger improvements in that > >>> timeframe? (For example there is the idea to add pin numbers for the > >>> mechanical mounting pins of connectors which would require renaming of > >>> footprints to allow better footprint filters.) > >> > >> For the libs, docs, and translations, I'm ok if we hold off tagging > >> until the stable release if that works for you. > > > > Correct as this needs to be done by the respective sub parts like the > > documentation or library team(s). > > > >> For rc releases, we can just package these items as they stand at the > >> moment. > > Also correct, 'rc' means nothing other then this is a release candidate, > > not to be considered as a final and stable release. But build tools an > > chains need to be tested and improved, workflows needs to be adopted to > > new versions or used tools ... > > Understood. > > > > >> I would not let this drag on too long. KiCad is in pretty good shape > >> so I'm hoping for a shorter rc period before the stable release than > >> we typically have. Of course this all depends on how quickly we can > >> fix any critical bugs that show up during the rc period. > > It's no shame to build more than one RC candidate and gives > > distributions also the chance to get better in touch with the new > > version and also increases the chance to get more feedback from people > > how are impossible or don't want to build the software by themselves. > > > > I will give everyone plenty of time to complete the non-source related > work. It's just that there are very few critical bugs compared to the > v4 branch so I am hopeful that v5 will not take 4 months from branch to > release. > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > Post to : kicad-developers@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > More help : https://help.launchpad.net/ListHelp > <https://help.launchpad.net/ListHelp> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > Post to : kicad-developers@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > More help : https://help.launchpad.net/ListHelp > <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
