accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
Date Tue, 07 Oct 2014 03:41:40 GMT
True. Everything I'm thinking of would work with no master, but that might
be confusing, and might break some tooling without extra effort (which
branch is default when cloning?). We also kind of assume that the master
branch is forward-moving only, but other branches are disposable and can be
rebase'd, deleted, re-created, etc.

Alternatively, if people understood that a "2.0" branch is a "future"
branch when 1.7 (master) is the "current", that'd work, too... I just worry
that people will merge it poorly.

I suppose the best option, then, is probably to keep the status quo, and
use a branch name like "ACCUMULO-####" which represents the overall work
for a particular future release plan, instead of a name which looks like a
maintenance branch.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Mon, Oct 6, 2014 at 10:59 PM, William Slacum <
wilhelm.von.cloud@accumulo.net> wrote:

> It seems to me you can get everything you want by merely getting rid of
> master or making master just be the 1.7 branch. I'm not really concerned
> about the name, because it's easy enough to figure out. Master duplicating
> a tag doesn't really seem useful to me, save for "here's the highest
> version we have released", which is of limited utility when a user can just
> check the tags. I don't see the point in having master be something for the
> sake of having master.
>
>
>
> On Mon, Oct 6, 2014 at 9:19 PM, Josh Elser <josh.elser@gmail.com> wrote:
>
> > Christopher wrote:
> >
> >> What purpose does the master branch serve if it's just the same as the
> >>> last
> >>> >  major release tag?
> >>> >
> >>> >
> >>>
> >> I think Josh had some specific opinions on this, but the general idea
> from
> >> what I understood was that master is supposed to be stable...
> >> representative of the latest, most modern release, because it's what a
> new
> >> contributor would expect to fork to create a patch. That's hard to do if
> >> the goalpost is moving a lot, and it makes feature merges more
> >> complicated,
> >> since contributors have to rebase or merge themselves in order to
> create a
> >> patch that merges cleanly. Having a stable master makes it very easy to
> >> contribute to the most recent release.
> >>
> >
> > No, I don't really care for a stable-only master (I think I diverge from
> > the git-flow model in that regard). I like master to just be a
> > "commits-go-here" area more than anything.
> >
>

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