Overall, I like this plan. Ideally, it'd be best if we could limit our
active branches to major versions and avoid creating major version branches
while we still are waiting on a previous major release's last minor release.
Once we've fully transitioned to a new versioning scheme, what do we expect
the steady state to be?
How about something like the following:
* We vote on a release plan that establishes a new major version
* major version created in jira
* wrap up last planned minor release on previous major version
* During this time, keep any incompatible patches meant for hte major
version in jira
* release last minor release of previous major version
* create new major version branch, remove previous major version branch
* apply patches from jira for new major version
This way we only have one major development branch at a time. When there
are new bug fixes that come in for a supported version we can create a
short-lived branch off of previous releases. If we're talking about only
having Critical+ issues go into bugfix releases, it should be relatively
easy to include them for all minor releases in our supported major
release(s).
I'd also like us to formally define major version lifecycle when we vote on
a new release plan for that major version. It's probably best if the
end-of-life is tied to the release of the next major version, so that we
have more incentive to avoid rapidly doing many major releases.
There are two other things in Christopher's original message I'd like to
discuss, but I'm not sure if they'd be better served in a different thread?
1) 1.7.0-SNAPSHOT in expectation for a forthcoming minor release
I don't think we ever finished the discussion of what to do with 1.x once
we have a 2.x out the door. I'd like to reiterate my concern that mixing
versioning number schemes in 1.x is confusing. Every other 1.x release in
the line has been a major release. It will be very hard to break that
expectation.
2) would have to discuss what kinds of things we'd want in such a release.
Minimally, I want ACCUMULO-1691
It's my understanding that ACCUMULO-1691 will break wire compatibility,
yes? If we're calling 1.7.0 a minor release, I do not want wire
compatibility broken in a minor release. If we're planning to only include
critical+ issues on bugfixes, then we need to make sure minor version
upgrades are low risk.
I know we haven't finished our discussion about what our compatibility
statement will cover and I'd like to have it in place before we do a
release under a new versioning scheme (wether or not that includes changing
the versioning within 1.x).
On Mon, May 12, 2014 at 10: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
>
--
Sean
