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 <bhava...@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.el...@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.el...@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 >
