[DISCUSS] Release policy update for handling feature branches

[aditi hilbert <ad...@runtime.io>]

Hi all,

It’s good to see our Release policy going into effect post 1.0 release. The develop branch is gone and feature branches have emerged. Smaller changes are being merged into the master branch which is now relatively up to date. Most of the feature branches are going to be long-lived, so wanted to discuss how to manage them efficiently. 

Typically, there is an “owner” for each feature branch who oversees the merges into that branch and periodically updates it with changes from master to keep it aligned with master and leverage recent changes. Currently we have “bluetooth5” - so we would need an owner for that. I can see other connectivity stacks (e.g. LoRa, sub-GHz) being built on separate feature branches. 

Please share your thoughts, concerns, suggestions. And do we have a volunteer for owning the “bluetooth5” feature branch? :)

thanks,
aditi

Re: [DISCUSS] Release policy update for handling feature branches

[aditi hilbert <ad...@runtime.io>]

> On Apr 20, 2017, at 5:04 AM, Szymon Janc <sz...@codecoup.pl> wrote:
> 
> Hi,
> 
> On Friday, 14 April 2017 21:07:04 CEST will sanfilippo wrote:
>> I think you are correct about this. Someone needs to determine which pull
>> requests against master need to get merged into the various branches.
>>> On Apr 14, 2017, at 11:54 AM, aditi hilbert <ad...@runtime.io> wrote:
>>> 
>>> Hi all,
>>> 
>>> It’s good to see our Release policy going into effect post 1.0 release.
>>> The develop branch is gone and feature branches have emerged. Smaller
>>> changes are being merged into the master branch which is now relatively
>>> up to date. Most of the feature branches are going to be long-lived, so
>>> wanted to discuss how to manage them efficiently.
>>> 
>>> Typically, there is an “owner” for each feature branch who oversees the
>>> merges into that branch and periodically updates it with changes from
>>> master to keep it aligned with master and leverage recent changes.
>>> Currently we have “bluetooth5” - so we would need an owner for that. I
>>> can see other connectivity stacks (e.g. LoRa, sub-GHz) being built on
>>> separate feature branches.
>>> 
>>> Please share your thoughts, concerns, suggestions. And do we have a
>>> volunteer for owning the “bluetooth5” feature branch? :)
>>> 
>>> thanks,
>>> aditi
> 
> I agree that there should be a dedicated person responsible for each of 
> feature branch. I can handle bluetooth5 branch for time being :-)
> 
> As for how it should be done I'd see it that master is periodically merged 
> back into feature branch. The rule of thumb would be that feature branch would 
> be always ready to be merged back into master without conflicts.
> 
Agreed.

> How does this sound?
> 

Sounds great! Thank you for volunteering to keep the bluetooth5 branch up to date with master.

aditi

> -- 
> pozdrawiam
> Szymon Janc

Re: [DISCUSS] Release policy update for handling feature branches

[Szymon Janc <sz...@codecoup.pl>]

Hi,

On Friday, 14 April 2017 21:07:04 CEST will sanfilippo wrote:
> I think you are correct about this. Someone needs to determine which pull
> requests against master need to get merged into the various branches.
> > On Apr 14, 2017, at 11:54 AM, aditi hilbert <ad...@runtime.io> wrote:
> > 
> > Hi all,
> > 
> > It’s good to see our Release policy going into effect post 1.0 release.
> > The develop branch is gone and feature branches have emerged. Smaller
> > changes are being merged into the master branch which is now relatively
> > up to date. Most of the feature branches are going to be long-lived, so
> > wanted to discuss how to manage them efficiently.
> > 
> > Typically, there is an “owner” for each feature branch who oversees the
> > merges into that branch and periodically updates it with changes from
> > master to keep it aligned with master and leverage recent changes.
> > Currently we have “bluetooth5” - so we would need an owner for that. I
> > can see other connectivity stacks (e.g. LoRa, sub-GHz) being built on
> > separate feature branches.
> > 
> > Please share your thoughts, concerns, suggestions. And do we have a
> > volunteer for owning the “bluetooth5” feature branch? :)
> > 
> > thanks,
> > aditi

I agree that there should be a dedicated person responsible for each of 
feature branch. I can handle bluetooth5 branch for time being :-)

As for how it should be done I'd see it that master is periodically merged 
back into feature branch. The rule of thumb would be that feature branch would 
be always ready to be merged back into master without conflicts.

How does this sound?

-- 
pozdrawiam
Szymon Janc

Re: [DISCUSS] Release policy update for handling feature branches

[will sanfilippo <wi...@runtime.io>]

I think you are correct about this. Someone needs to determine which pull requests against master need to get merged into the various branches.

> On Apr 14, 2017, at 11:54 AM, aditi hilbert <ad...@runtime.io> wrote:
> 
> Hi all,
> 
> It’s good to see our Release policy going into effect post 1.0 release. The develop branch is gone and feature branches have emerged. Smaller changes are being merged into the master branch which is now relatively up to date. Most of the feature branches are going to be long-lived, so wanted to discuss how to manage them efficiently. 
> 
> Typically, there is an “owner” for each feature branch who oversees the merges into that branch and periodically updates it with changes from master to keep it aligned with master and leverage recent changes. Currently we have “bluetooth5” - so we would need an owner for that. I can see other connectivity stacks (e.g. LoRa, sub-GHz) being built on separate feature branches. 
> 
> Please share your thoughts, concerns, suggestions. And do we have a volunteer for owning the “bluetooth5” feature branch? :)
> 
> thanks,
> aditi
> 
> 
> 
> 
> 
>