hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: Questions wrt security branches
Date Tue, 03 May 2011 21:04:18 GMT
On Tue, May 3, 2011 at 1:31 PM, Owen O'Malley <omalley@apache.org> wrote:
> On May 3, 2011, at 9:35 AM, Eli Collins wrote:
>> Do all changes for 0.20.2xx release go through branch-0.20-security,
>> then get merged to a particular -2xx branch?
> I've discussed this before on the lists,  but here goes:

Thanks.  I should have mentioned that I followed the thread below but
it was not clear that eg all changes have to go through -security to
ensure a -20(n+1) branch has the changes from -20n.


> branch-0.20-security is the major branch and all changes need to be committed to it.

Thanks for clarifying.

> The branches off of branch-0.20-security, namely branch-0.20-security-203 and branch-0.20-security-204
are the minor branches, which are branched off of branch-0.20-security every month or two.
Within a minor branch there are only bug fixes.

Why the new branches instead of releasing from branch-0.20-security
the way previous release branches (eg branch-0.20) have worked?

> So this release, we are trying to get out the door is A bug fix to it would
go into New features like disk fail in place go into

Shouldn't new features go to trunk and then the next minor release?

According to the project's current version scheme
(http://wiki.apache.org/hadoop/Roadmap eg major.minor.point), a point
release (eg the 203 in 0.20.203) "do not introduce new features or
make other improvements other than fixing bugs."

Is this a proposal to make branch-0.20-security a feature branch that
does releases, and the new version number is necessary to allow for
new features?  Doesn't this allow for releases from
branch-0.20-security and trunk to diverge in terms of feature set?

I think people would prefer we spend our energy putting new features
(not yet in trunk) in trunk so we don't create divergent releases.
Creating a new branch for new features seems like it will prolong our
current situation.

>> Why is there a new 4th component to the version number?
> The problem is that we need minor versions and there isn't space in the current scheme.
It would probably be clearer, if we called this release 1.0. Then this looks like:
> branch-1
> branch-1.0
> branch-1.1
> with point releases off of it. When I floated the idea of using 1.0 last time, there
was more consensus around using the 0.20.20X.Y naming.

I remember there being resistance to calling it 1.0 but I don't
remember consensus on a new feature branch or 4 part version scheme.

Not sure mirroring the YDH version numbers is what's most sense for an
Apache release:
Arun's proposal of using 0.20.100 seemed more logical.

>> I noticed a fix version showed up recently.  Where's the
>> branch for that?
> It hasn't branched yet, but it will come off of branch-0.20-security.

So a fix for (like any fix for a version not yet branched)
only gets checked into branch-0.20-security. Makes sense.

Thanks for the clarifications.


View raw message