Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> GIT


On Tue, Jun 4, 2013 at 3:09 PM, Christopher <[EMAIL PROTECTED]> wrote:

> I can get behind this also, but I have an additional suggestion that
> diverges from the proposed model at
> http://nvie.com/posts/a-successful-git-branching-model/ (suggested
> earlier in this thread):
>
> I'm not a fan of separate "master" and "develop" branches, since
> "master" is only used as a pointer for tracking the latest and
> greatest stable tag. I think just a "master" would be fine (for active
> development on the next anticipated major release), because I think
> it's safe to assume people know what tags are and how to use them if
> they want a stable version. If we *really* need a pointer, I'd rather
> call it "stable", as it's more explicit.
>

+1 for only having one infinite-lifetime branch.
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Tue, Jun 4, 2013 at 5:51 PM, Keith Turner <[EMAIL PROTECTED]> wrote:
> > On Tue, Jun 4, 2013 at 10:01 AM, Josh Elser <[EMAIL PROTECTED]>
> wrote:
> >
> >> On 6/4/13 9:35 AM, Keith Turner wrote:
> >>
> >>> On Tue, Jun 4, 2013 at 9:07 AM, Josh Elser<[EMAIL PROTECTED]>
>  wrote:
> >>>
> >>>  >Yay, Git. Wait...
> >>>> >
> >>>> >I was going to wait to respond until I collected all of the info, but
> >>>> >since I still haven't gotten that done yet, I figured I should just
> say
> >>>> >"sure".
> >>>> >
> >>>> >The one thing I do want to get hammered out is the general workflow
> we
> >>>> >plan to use. I believe that one "unstable" or "development" branch
> will
> >>>> >satisfy most use cases as we typically don't have much active
> >>>> development
> >>>> >against previous major releases.
> >>>> >
> >>>> >The thing I don't care for (putting it mildly) is long-running
> >>>> >minor-release branches. I'm curious of suggestions that people might
> >>>> have
> >>>> >for how to work around this. One
> >>>>
> >>>
> >>> Why?  What problems are you thinking of w/ long-running minor release
> >>> branches?
> >>>
> >>
> >> I do not like them. It's mainly a personal opinion. Most modern SCM
> tools
> >> (even that 'terrible' SVN) strongly encourage you to release early and
> >> often. As such, I don't like having branches named like tags/releases.
> This
> >> is mostly a personal opinion; however, you can also read that as
> opinions
> >> after using git for ~5 years.
> >>
> >
> > Discussed this w/ Christopher and Josh.  I understand Josh's point of
> view
> > a bit better now.  One thing I was unsure about was what to name these
> > transient branches for gathering bug fixes.  Christopher suggested using
> > snapshots, which seems very natural to me.
> >
> >   * For serious bugs in 1.4.3  take 1.4.3 tag and create 1.4.4-SNAPSHOT
> > branch
> >   * Merge bug fixes to 1.4.4-SNAPSHOT from bug fix branches
> >   * Eventually tag 1.4.4 and delete 1.4.4-SNAPSHOT branch
> >   * 1.4.5-SNAPSHOT would only be created on an as needed basis.
> >
> > I think this is nicer than leaving a 1.4 branch around.
> >
> >
> >>
> >>>  >possibility would be to be git-tag heavy while being more lax on
> >>>> official
> >>>> >apache releases.
> >>>> >
> >>>> >Merits:
> >>>> >- Less merging through 2-3 branches which a bug-fix might apply
> >>>> >(1.4->1.5->1.6)
> >>>> >- Less clutter in the branch space (could be moot if we impose some
> sort
> >>>> >of "hierarchy" in branch names, e.g. bugfixes/ACCUMULO-XXXX,
> >>>> >minor/ACCUMULO-XXXX)
> >>>> >- Quicker availability of fixes for consumers (after a fix, a new
> tag is
> >>>> >made)
> >>>> >
> >>>> >Downsides:
> >>>> >- Could create more work for us as we would be noting new minor
> >>>> releases.
> >>>> >Does Christopher's release work mitigate some/most of this?
> >>>> >- Creating git-tags without making an official release_might_  skirt
> a
> >>>>
> >>>> >line on ASF releases. Some artifact that is intended for public
> >>>> consumption
> >>>> >is meant to follow the release process.
> >>>> >
> >>>> >
> >>>>
> >>> It seems like you have a specific workflow in mind, but its not clear