Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Pig >> mail # dev >> Our release process

Copy link to this message
Re: Our release process
Looks like everyone is interested in having frequent releases - I don't see anyone disagreeing with that.

Regarding "If a patch makes the release branch unstable, we revert it" - what are the criteria? If we can't decide on the criteria on this thread (already pretty long) then lets get the release trains going. We can revisit the criteria for inclusion of bug fixes when that happens.

 From: Julien Le Dem <[EMAIL PROTECTED]>
Sent: Thursday, November 29, 2012 9:45 AM
Subject: Re: Our release process
The release branch receives only bug fixes. Patch level releases (3rd
version number) are issued out of the release branch and introduce
only bug fixes and no new features.
Deciding whether a patch is applied to the release branch is based on
preserving stability (as Bill said). If a patch makes the release
branch unstable, we revert it.
New features are added to trunk where new major and minor releases will happen.
If we need a new feature out then we make a new minor release.
Doing frequent releases is the industry standard and will resolve
conflicts around what should go in a release branch.

Making a new release is currently painful *because* we wait so long in
between two releases. Let's fix that.


On Wed, Nov 28, 2012 at 10:09 PM, Santhosh M S
> Since releasing a major version once a month is agressive and we have not released on a quarterly basis, we should allow commits to a released branch to facilitate dot releases.
> If we are allowing commits to a released branch, the criteria for inclusion can be created anew or we use the industry standards for severity (or priority). It could be painful for a few folks but I don't see better alternatives.
> Regarding reverting commits based on e2e tests breaking:
>         1. Who is running the tests?
>         2. How often are they run?
> If we have nightly e2e runs then its easier to catch these errors early. If not the barrier for inclusion is pretty high and time consuming making it harder to develop.
> Santhosh
> ________________________________
>  From: Bill Graham <[EMAIL PROTECTED]>
> Sent: Wednesday, November 28, 2012 11:39 AM
> Subject: Re: Our release process
> I agree releasing often is ideal, but releasing major versions once a month
> would be a bit agressive.
> +1 to Olga's initial definition of how Yahoo! determines what goes into a
> released branch. Basically is something broken without a workaround or is
> there potential silent data loss. Trying to get a more granular definition
> than that (i.e. P1, P2, severity, etc) will be painful. The reality in that
> case is that for whomever is blocked by the bug will consider it a P1.
> Fixes need to be relatively low-risk though to keep stability, but this is
> also subjective. For this I'm in favor of relying on developer and reviewer
> judgement to make that call and I'm +1 to Alan's proposal of rolling back
> patches that break the e2e tests or anything else.
> I think our policy should avoid time-based consideration on how many
> quarters away are we from the next major release since that's also
> impossible to quantify. Plus, if the answer to the question is that we're
> more than 1-2 quarters from the next release is "yes" then we should be
> fixing that release problem.
> On Wed, Nov 28, 2012 at 10:22 AM, Julien Le Dem <[EMAIL PROTECTED]> wrote:
>> I would really like to see us doing frequent releases (at least once
>> per quarter if not once a month).
>> I think the whole notion of priority or being a "blocker" is subjective.
>> Releasing infrequently pressures us to push more changes than we would
>> want to the release branch.
>> We should focus on keeping TRUNK stable as well so that it is easier
>> to release and users can do more frequent and smaller upgrades.