accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes
Date Mon, 12 May 2014 15:44:23 GMT
Why eliminate the 1.6.1-SNAPSHOT branch for 1.7.0-SNAPSHOT? Why not just
branch the master and insert a 1.7.0-SNAPSHOT into our workflow after
1.6.1-SNAPSHOT and before master?


On Mon, May 12, 2014 at 11:10 AM, Bill Havanki <bhavanki@clouderagovt.com>wrote:

> I like this plan overall. I am definitely in favor of more frequent,
> lighter-weight bugfix releases. We can start to move toward a regular
> schedule of them, based on whether there is enough there to warrant one
> each month / two months / whatever.
>
> We could start by branching off 1.6.0 now, and merging in whatever bug fix
> commits make sense (pending a discussion as Christopher suggested). It can
> be kept in a ready-to-release condition, for whenever it's "time" for
> 1.6.1.
>
> What about 1.5.x? That will still receive feature changes as well as bug
> fixes, I assume, until it goes EOL.
>
>
> On Mon, May 12, 2014 at 10:44 AM, Josh Elser <josh.elser@gmail.com> wrote:
>
> > On 5/12/14, 10:41 AM, Keith Turner wrote:
> >
> >> On Sun, May 11, 2014 at 6:54 PM, Josh Elser<josh.elser@gmail.com>
>  wrote:
> >>
> >>  >SGTM. Looks like there aren't currently any fixes of much substance
> for
> >>> >1.6.1 presently, but there are a few that would make for a very-low
> >>> impact
> >>> >1.6.1, and a good 1.5.2 which also includes the fallout tickets
> shortly
> >>> >after 1.5.1. Timeframe looks good to me too.
> >>> >
> >>> >If we can get that reduced test burden for "real" bug-fix releases
> >>> >hammered out, a month sounds good to me.
> >>>
> >>
> >> Rather than reduce the test burden, it would be nice to make the cluster
> >> testing more automated like you and other have discussed.
> >>
> >
> > I think that would be a good parallel goal, but I would still think that
> 7
> > days of testing for a bug-fix release is excessive. Most times for me the
> > pain is getting resources to test for such a long period, not necessarily
> > setting up the test.
> >
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283
>

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