Hi IoTivity Devs,

In the past, we've had a relatively unstable master branch, which has caused us 
to stick to release branches perhaps longer than we'd like, to avoid battling a 
constant stream of regressions.  These long-lived branches entail more work 
cherry picking release branch changes into master, tracking status on two 
separate branches for longer, etc.

Comarch has recently finished installing a nightly regression test using the 
OCF Certification Test Tool, and will be running it against master every night 
going forward.  We'll get an email within 24 hours if an OCTT regression is 
introduced.  I'm very happy about this :)  This - along with existing Jenkins 
tests - should keep new regressions to a minimum.  This in turn means I think 
we can shorten the lifecycle for our release branches.

For the next release ("Bangkok Point Release", a.k.a. 2.1.0) I'd like to try a 
much shorter release branch plan.  We'd move all development to master until we 
basically are code complete (and passing OCTT by virtue of the nightly 
regression test).  At that point we'd create a 2.1-rel branch, create a 
2.1.0-RC0 tag, and run through QA process.  The only patches against 2.1-rel 
would be to fix bugs found in this final QA cycle (which again hopefully will 
be minimal thanks to our nightly test cycles).  As soon as the QA cycle 
finishes we'd make the 2.1.0 tag, cherry pick the 2.1-rel branch back to 
master, and resume working on master.  The goal would be to have active 
development on the 2.1-rel branch last less than a month (as compared to 
multi-month lifespan of previous release branches).

I think one effect of this is that large changes, such as a re-architecture or 
major new feature, should be developed on a separate branch rather than on 
master, so that master doesn't contain merged patches that form incomplete 
changes.  I personally think this is good development practice anyway, but it's 
not the way IoTivity master has been treated previously.

Are there any objections to this plan?  Comments or suggestions to make it 
better?  I'd like to agree on this formally at next week's OSWG weekly CC (Weds 
9am PST, see OCF Kavi website if you'd like to attend), so that we can EOL the 
1.4-rel branch and get everyone back on master asap.

Thanks,
Nathan


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9923): 
https://lists.iotivity.org/g/iotivity-dev/message/9923
Mute This Topic: https://lists.iotivity.org/mt/25216172/21656
Group Owner: iotivity-dev+ow...@lists.iotivity.org
Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to