[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)
From:       Artem Barger <artem () bargr ! net>
Date:       2016-05-31 14:56:34
Message-ID: CAG3-T352DfiqP7U_U0=JjQacn0evi+QGqVX_R5PMMVD3ZMGYxg () mail ! gmail ! com
[Download RAW message or body]


On Tue, May 31, 2016 at 5:43 PM, Rob Tompkins <chtompki@gmail.com> wrote:

> On May 31, 2016, at 10:21 AM, Matt Sicker <boards@gmail.com> wrote:
> >
> > Why not just rename master to something like stable, then rename develop
> to
> > master? Less confusing to people who don't know about git-flow.
>
> Generally when I think about an arbitrary github project I would think
> that the "master" branch reflects the latest released code, and the
> "develop" branch should reflect the inflight development. Assuming that the
> history of the branches is properly maintained, a topic branch based in
> master should be able to be worked on and then PR'd into develop (assuming
> that the individual doing the work has accommodated for the merge conflicts
> in migrating it to develop).
>
> If the project is mirrored in git, then I would argue that the semantics
> of the version control system should be used as opposed to using our own
> semantics because then the arbitrary developer coming from another git
> project can quickly figure out how to work with the codebase.
> ​
>

​Well, IMO an average GutHub project usually uses a master branch as
ongoing branch for development and has "release" branch or even several
branches​ in case there are a couple of versions for release. Of course
working w/ feature branch for separate tasks merging/rebasing them later
into the master. But I think this is a matter of project policies and
agreements, important branches usually protected from accepting direct
commits into them.

BR,
- Artem.


[prev in list] [next in list] [prev in thread] [next in thread]