Development lifecycle

[pan-]

As we advance our work, the upstream repository moves forward too. It would be beneficial for us to keep our work in sync with what is happening upstream.

I propose the following rules for branches:

• master is locked from local changes. It is updated at a regular interval (week ? Sprint ?) with code from upstream.
• Our pull requests are merged into the development branch. When master is updated, development is rebased against it.
• To verify that we are not breaking anything CI workflow from upstream are run in this repository.
• Feature development happens in dedicated feature branch to isolate the feature from external changes while its being developed.
• At the end of each Sprint, the development branch is rebased against the master branch and a release is created.

@fkjagodzinski @lukgni @ATmobica What do you think of the proposed approach ?
What would be the ideal rebase time for master and development ?

[lukgni]

LTGM. In my opinion we should update 'master' at the beginning of every sprint (2 weeks).
We may consider adding additional point which will cover situation when some hotfixes landed on the original repo. In that case we should update 'master' and rebase branches without waiting for the end of the sprint/week.

[ATmobica]

Hi, This approach sounds good to me. I agree with Lukasz. The update session should be at the beginning of the sprint to start new tasks with the up to date repo. Artur Tynecki Senior Software Engineer / Group Manager RingCentral: 2455 Skierniewicka 10a, 01-230 Warszawa, Poland pon., 1 lut 2021 o 02:27 Lukasz Gniadzik <notifications@github.com> napisał(a):

…

LTGM. In my opinion we should update 'master' at the beginning of every sprint (2 weeks). We may consider adding additional point which will cover situation when some hotfixes landed on the original repo. In that case we should update 'master' and rebase branches without waiting for the end of the sprint/week. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASOMKM5REUL2T6TH4LCTVGDS4X7PZANCNFSM4WZFZHPQ> .

-- Mobica is a global software services company, delivering and enabling technologies that transform business outcomes for the leading brands in Automotive, Silicon, FinTech, Media and Telecoms. Headquartered in Wilmslow UK with offices across Europe and the US, our established technical and delivery excellence in high quality software engineering drives success for our multinational customers on every continent, every day. Find out more at Mobica.com <https://www.mobica.com> Mobica Limited is a limited company registered in England and Wales with registered number 05169596 and VAT registered number 223837508. Our registered office is at Crown House, Manchester Road, Wilmslow, Cheshire, SK9 1BH, UK. This message is intended solely for the addressee(s) and may contain confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment. Mobica complies with all requirements of GDPR and other relevant data protection law. You can view our Privacy Policy at https://mobica.com/privacy-policy/ <https://mobica.com/privacy-policy/>

[fkjagodzinski]

Looks like we all agree. 😎 I'd add one modification:

* At the end of each Sprint, the development branch is rebased against the master branch and a release is created.

How about releasing the development first (in a state we know works fine) and after that, rebasing it onto current master?

[pan-]

Thanks you all for commenting, there's a consensus to release the development branch at the end of the spring and rebase onto master at the beginning of the sprint. I agree.

I will create a document in the wiki to reflect our process.