accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Reduced testing burden for bug-fix releases
Date Thu, 19 Jun 2014 19:20:21 GMT
+1 for reduced testing burden for bugfixes and a change in the guidelines
to reflect that.

Christopher L Tubbs II

On Thu, Jun 19, 2014 at 3:13 PM, Josh Elser <> wrote:

> As we're starting to consider 1.5.2 and 1.6.1 coming out in the near
> future, I want to revisit a discussion[1] I started at the end of April
> regarding the "testing burden" that is currently set forth in our release
> document[2].
> What I'm proposing is to modify the language of the release document to be
> explicit about the amount of testing needed. For bug-fix, "minor" releases
> (e.g. 1.5.2 and 1.6.1), the 7 days of testing using continuous ingest and
> randomwalk (with and without agitation) will be clearly defined as "may"
> instead of "should" or "must" language. If the resources are available, it
> is recommended that some longer, multi-process/node test is run against the
> release candidate; however, it is not required and should not prevent us
> from making the minor release.
> I will also include language that strongly recommends that the changes
> included in the "minor" release be vetted/reviewed as a way to mitigate the
> risk of shipping new regressions.
> I am not recommending that the language be changed for "major" releases
> (e.g. 1.7.0 and 2.0.0) as these releases still imply significant new
> features or internal changes.
> Unless someone informs me otherwise, I will treat this as a normal
> lazy-consensus approval. Assuming we move closer to "proper" semantic
> versioning for 2.0.0, I believe these updated guidelines will change again.
> I do however think there is merit in making this change now so that we can
> get the good bugs that we've fixed out to our users.
> Let me know what you think. I will wait, at least, the prescribed three
> days before changing any thing.
> - Josh
> [1]
> 201404.mbox/
> [2]

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