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. > > 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/ 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 Post to : email@example.com Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp