kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

2018-02-09 15:05 GMT+01:00 Wayne Stambaugh <stambaughw@xxxxxxxxx>:

> 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/
>
> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>