celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Re: [LAZY] Use master as development branch
Date Thu, 23 Apr 2020 16:20:06 GMT
Op do 23 apr. 2020 om 09:10 schreef Pepijn Noltes <pepijnnoltes@gmail.com>:

> Hi All,
>
> +1 for me.
>
> On Thu, Apr 23, 2020 at 6:34 AM Alexander Broekhuis
> <a.broekhuis@gmail.com> wrote:
> >
> > I'm not against this. But would like some more info on how we are going
> to work with this.
> >
> > What is your proposal wrt feature, bugfix and release branches?
> > One concern I have is that last one. With a dev/master split, a release
> branch can be used to prepare a release to master, while dev is used to
> continue merging new features to.
> > How should we do that now?
>
> Maybe I am oversimplifying this, but IMO almost everything will be the
> same, expect that there is no master branch pointing to the latest
> release.
> So instead of creating a tag, merging to master and then merging to
> develop. The last part can be dropped.
>

Sounds good enough for me. Perhaps this is me lacking some git knowledge,
but the tag is on the branch, and the branch can be deleted later. Is that
a problem? Just asking to be sure. I think it is important to be able to
continue on master with new development.


>
> If we follow our release procedure [1] we also use a release branch
> and only the "Merge to master and create GIT tag" needs to change.
> I rather have that we move forward and when updating the website also
> update the "Merge to master and create GIT tag" of the release
> procedure.
>
> If any more documentation is needed we can address this on a later date.
>

What's the rush with this? Let's do it properly at once. It is not like we
are having any problems at the moment. Also IMHO, I don't think what I am
requesting is anything difficult/strange.

Like I said, I am in favour, but just prefer to do it in one go...


>
> [1] https://celix.apache.org/contributing/releasing.html
>
> >
> > Before doing the actual change, can you draft up a developer page for it?
> >
> > Because of this, for now a -1. Will gladly change to a +1 if things are
> clear!
> >
> > --
> > Met vriendelijke groet,
> >
> > Alexander Broekhuis
> > On 22 apr. 2020 19:22 +0200, Roy Lenferink <rlenferink@apache.org>,
> wrote:
> > > Hi all,
> > >
> > > I'd like to propose the idea of using the 'master' branch as our
> development branch. Why?
> > > - ASF releases are promoted through the ASF mirroring system. Our
> website is built on top of this
> > > allowing the user to select a mirror for downloading the release.
> Cloning the git repository is not
> > > the first thing a user does. Even if users plan to use the git
> repository they can use a specific tag.
> > > - The ASF allows committers to use a so-called .asf.yaml file [1] for
> changing repository settings.
> > > However, changes to this file are only propagated when made on the
> master (or trunk) branch.
> > >
> > > IMO our current workflow with develop/master just adds extra
> complexity. Other ASF projects are
> > > using the master branch as their development branch as well, e.g.
> Spark [2], Dubbo [3], Flink [4] &
> > > HBase[5].
> > >
> > > If no objections within 72 hours I'll merge the 'develop' branch to
> our 'master' branch, update the
> > > current open pull requests to have 'master' as base branch, open a
> ticket to remove branch
> > > protection for the develop branch & update the website to point to the
> master branch for changes
> > > instead of the develop branch.
> > >
> > > See also [6] for a short discussion on this topic already.
> > >
> > > Best,
> > > Roy
> > >
> > > [1] https://s.apache.org/asfyaml
> > > [2] https://github.com/apache/spark
> > > [3] https://github.com/apache/dubbo
> > > [4] https://github.com/apache/flink
> > > [5] https://github.com/apache/hbase
> > > [6] https://github.com/apache/celix/pull/202#issuecomment-616429007
>


-- 
Met vriendelijke groet,

Alexander Broekhuis

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message