hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zach York <zyork.contribut...@gmail.com>
Subject Re: [DISCUSS] What to do with branches for EOL versions
Date Mon, 15 Jul 2019 19:16:27 GMT
I agree that deleting EOM branches is the best approach (with tags).
Having a branch for an EOM line doesn't make sense since a branch signifies
(and/or promotes) active development.
Having a tag signifies that this line is static and is a point-in-time
pointer to the branch. In the worst case scenario,
we can still create a branch off of the tag if we want to 'revive' the

This also simplifies life for committers as it will be easier to know which
branches are 'active' since those will be the only
branches that exist.

On Mon, Jul 15, 2019 at 8:12 AM Wellington Chevreuil <
wellington.chevreuil@gmail.com> wrote:

> I think delete EOM branches and keeping only tags sounds reasonable, but
> ain't much experienced on releases management, honestly. Do we know what's
> the standard among most apache projects? Maybe we could follow those?
> Em seg, 15 de jul de 2019 às 15:27, Josh Elser <elserj@apache.org>
> escreveu:
> > (Sending this note for Busbey as he's chasing other stuff)
> >
> > He had sent a note to private asking what had happened to branch-1.2. In
> > my cleanup of old branches to try to reduce our Jenkins usage at the
> > request of Infra, I created a git tag instead of the branch: branch-1.2
> > was deleted remotely, and the tag branch-1.2-EOM was created.
> >
> > Busbey said he would put back branch-1.2 (at least temporarily), but
> > that we should discuss what we want the "normal" to be going forward.
> >
> > I can see the confusion in folks who are "used to" the "branch-x[.y]"
> > notation being confused when the upstream branch is no longer present.
> > However, I can also see the "EOM" tag for the same "branch-x[.y]" being
> > self-explanatory (or at least a good indication that maybe a user is
> > trying to interact with a development line that we no longer maintain).
> >
> > How do others think we should handle branches which we voted on
> > no-longer maintaining releases for?
> >
> > - Josh
> >

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