[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Branching strategy
|
I agree with this in general. I would maybe keep it a bit simpler and create only 1.0.x branch for now and do 1.1 (and follow-up minor releases) from master. We can introduce 1.x branch when we encounter braking changes or start planning for 2.0. This would make it a bit easier to maintain (less rebasing/cherry-picking).
Hi community,
now that we have released 1.0.0 we should take a little time to think
about the branching strategy that we want to pursue in the future.
It is quite obvious that we cannot simply go on developing on master
anymore because we would easily run into problems with semantic
versioning, i.e. if we commit a new feature to master, we cannot create
a 1.0.x service release from that revision anymore.
So here's a straw man for you to shoot at:
We create a 1.0.x branch off of the 1.0.0 tag for doing service releases.
We create a 1.x branch for working on minor releases.
We work on 2.0.0 on master (or a dedicated 2.0.0 branch)
Note that all this will require us to be even stricter with scoping
individual commits, because we will need to cherry pick (or merge)
commits on the 1.0.x branch to 1.x and commits on 1.x to master (2.0.0)
without breaking semantic versioning.
WDYT?
--
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Ullsteinstr. 128
12109 Berlin
GERMANY
www.bosch-si.com
Registered Office: Berlin, Registration Court: Amtsgericht
Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke;
Managing Directors: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/hono-dev
--
