We need one branch that holds all new API changes before those are released (> 4 months currently): either it's master or api-next. If we change API development to master, then applications would need follow the latest release branch instead of master. At least previous there was resistance to change master into API development branch.
Separate topic branches for API changes won't scale ... we would not have a common view (e.g. for 4 months) what the API is before all those are merged together. Implementation changes are easier in topic branches as there's less dependency to other files and applications (other files and apps already agree what the API is). Api-next does not cause the problem (big delta), it's caused by the lack of steady release cycle. The big delta won't go away before we have a short enough release cycle (merge often => small delta). -Petri > -----Original Message----- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill > Fischofer > Sent: Wednesday, October 25, 2017 6:53 PM > To: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org> > Cc: lng-odp-forward <lng-odp@lists.linaro.org> > Subject: Re: [lng-odp] API-next branch > > I'm all for using topic branches, especially since we've switched to > GitHub > and most contributors are now familiar with it and using pull requests > rather than raw patches sent to the mailing list. The whole reason for > api-next was to separate in-progress API changes from regular maintenance > patches since they were all mixed together on the mailing list. The PR > structure is much cleaner in that regard. > > IPsec in particular clearly could have been a separate branch. We've > talked > about doing this in the context of 2.0 as well since that's also going to > involve some major subsystems that could benefit from collaborative > development before being merged back into the 2.0 main development branch. > > > On Wed, Oct 25, 2017 at 10:39 AM, Dmitry Eremin-Solenikov < > dmitry.ereminsoleni...@linaro.org> wrote: > > > Hello, > > > > I tried to actually check, which patches are sitting in the api-next. > > And actually I failed > > to do that in a timely manner. git cherry produces a list of patches, > > that contains a lot of patches, which already landed to the master. > > > > Quick proposal would be to stop using api-next as a long-lived branch > > which received updates from master and rather use it as a branch being > > regularly rebased on top of current master. > > > > Another possiblity would be to abandon api-next completely, develop > > features on topic branches, which get merged to master, rather than to > > api-next. At least this would save us from situations, when there is > > API definition (or change), but no actual implementation behind. > > > > -- > > With best wishes > > Dmitry > >
