[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Branching strategy
|
Great. I think then that we have an overall consensus about this. Let's wait a bit longer for more feedback, but we should include this info as the part of the developer documentation for future reference. Maybe we can create a "Project management guide" and provide formal more info about release process, branching/versioning info and build/test infrastructure?
This sounds great, Dejan :-)
On 28.10.19 18:43, Dejan Bosanac wrote:
> Hi all,
>
> here are some proposals on how we can manage releases and branches going
> forward, based on the number of conversations during EclipseCon.
>
> * We should create 1.0.x release branch for potential service releases
> based on 1.0.0
I have already done that.
> * After every minor release we should create a corresponding service
> releases branch in the future (1.1.x, 1.2.x, 2.0.x, ....)
> * The master branch is the main development branch
> * We should try to do following minor releases in the same way as we did
> releases in the past
> * Every 4 weeks we create a milestone release e.g. 1.1-M1
> * After two minor releases we should try to create an actual
> minor release (1.1.0)
Sounds good to me. Based on that, we can create a road map in the
Eclipse PMI. However, it would probably be 1.1.0-M1 ;-)
> * Service releases are created only when needed, to fix critical bugs,
> security issues, etc.
> * Service release needs to contain minimal number of
> commits/cherry-picks in order to minimize upgrade issues
> * Service releases are always created for the current minor release
> * Service release can be created for previous minor releases based on
> the community demand and discussions
> * Breaking API changes should be implemented in a way that doesn't
> affect backward compatibility, by deprecating (but not removing) old API
> signatures if possible
> * Major releases are done when we can't avoid breaking backward
> compatibility, after amount of deprecated APIs have been accumulated or
> community thinks it's time for a major release
> * Major release will remove all current API deprecations
I agree in general that this is a good idea. However, we should be able
to make exemptions from that rule on a case by case basis in order to
allow for a smooth migration and if circumstances allow for it.
> * All these are just general guidelines, but every release decision
> should be discussed in the community. Exception could be made based on
> the current developments and discussions in the community.
>
+1
> This is just one proposal based on different conversations and best
> practices already used by many open source projects/communities. Please
> provide your feedback.
>
>
>
>
>
>
> On Mon, Oct 28, 2019 at 11:18 AM Jens Reimann <jreimann@xxxxxxxxxx
> <mailto:jreimann@xxxxxxxxxx>> wrote:
>
> I would also prefer to simply start with a "1.0.x release" branch,
> and create service releases as necessary.
>
> Main work, not creating breaking changes, should continue on the
> "master" branch. If we figure out we find no way around a breaking
> change, or think the time for 2.0.0 is right, we should revisit this
> discussion.
>
> Cheers
>
> Jens
>
> On Tue, Oct 22, 2019 at 10:12 AM Dejan Bosanac <dejanb@xxxxxxxxxxxx
> <mailto:dejanb@xxxxxxxxxxxx>> wrote:
>
> 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).
>
> On Tue, Oct 22, 2019 at 9:03 AM Hudalla Kai (INST/ECS4)
> <kai.hudalla@xxxxxxxxxxxx <mailto:kai.hudalla@xxxxxxxxxxxx>> wrote:
>
> 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 <http://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 <mailto: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
>
>
>
> --
> Regards
> --
> Dejan Bosanac
> http://sensatic.net/about
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx <mailto: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
>
>
>
> --
> Jens Reimann
> Principal Software Engineer / EMEA ENG Middleware
> Werner-von-Siemens-Ring 14
> 85630 Grasbrunn
> Germany
> phone: +49 89 2050 71286
> _____________________________________________________________________________
>
> Red Hat GmbH, www.de.redhat.com <http://www.de.redhat.com>,
> Registered seat: Grasbrunn, Commercial register: Amtsgericht
> Muenchen, HRB 153243,
> Managing Directors: Paul Argiry, Charles Cachera, Tom Savage,
> Michael O'Neill
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx <mailto: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
>
>
>
> --
> Regards
> --
> Dejan Bosanac
> http://sensatic.net/about
>
> _______________________________________________
> 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
>
--
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
--
