+1
On Wed, Nov 16, 2011 at 4:49 PM, Owen O'Malley wrote:
> +1 for release future 2xx releases as 1.x.y.
>
> I believe the right mapping is:
> rename branch-0.20-security to branch-1
> copy branch-0.20-security-205 to branch-1.0
>
> Then the 1.0.x releases will come off of the branch-1.0 and branc
On Wed, Nov 16, 2011 at 01:11PM, Matt Foley wrote:
> I support giving all three active code branches a clean start, on an equal
> footing:
>
> - The next release of 0.20-security (formerly expected as "0.20.205.1") to
> be 1.0.0, establishing branch-1.0
> - The next release of 0.22 to be 2.0.0, es
On 11/16/11 3:51 PM, "Nathan Roberts" wrote:
>On 11/16/11 4:43 PM, "Arun C Murthy" wrote:
>> I propose we adopt the convention that a new major version should be a
>>superset of the previous major version, features-wise.
>Just so I'm clear. This is only guaranteed at the time the new major
>ve
On 11/16/11 4:13 PM, "Doug Cutting" wrote:
>On 11/16/2011 03:51 PM, Nathan Roberts wrote:
>>> > Another definition is that a major release permits incompatible
>>>changes,
>>> > either in APIs, wire-formats, on-disk formats, etc.
>> Are our wire formats stable enough in all release lines that w
On Nov 16, 2011, at 3:02 PM, Doug Cutting wrote:
>
>
> Another definition is that a major release permits incompatible changes,
> either in APIs, wire-formats, on-disk formats, etc. This is more
> objective measure. For example, one might in release X+1 deprecate
> features of release X but st
+1 for release future 2xx releases as 1.x.y.
I believe the right mapping is:
rename branch-0.20-security to branch-1
copy branch-0.20-security-205 to branch-1.0
Then the 1.0.x releases will come off of the branch-1.0 and branch-1 will
be the upcoming 1.1.x releases.
-- Owen
+1 for 0.20.205.1 --> 1.0.0
On Tue, Nov 15, 2011 at 8:22 PM, Arun Murthy wrote:
> Please vote on naming 'future' releases off branch-0.20-security (with
> both security & append) as hadoop-1.x.x.
>
> We should also rename branch-0.20-security as branch-1.x.x.
>
> I propose we use the common 3-p
+1 for calling 0.20.205.1 as 1.0.0.
mahadev
On Tue, Nov 15, 2011 at 11:08 PM, Arun Murthy wrote:
> To be specific (both Eli and Eric pointed this) I'd like to clarify
> that we should call the upcoming 0.20.205.1 as 1.0.0 - this is in
> keeping with the 'look forward' theme.
>
> thanks,
> Arun
>
On 11/16/2011 03:51 PM, Nathan Roberts wrote:
>> > Another definition is that a major release permits incompatible changes,
>> > either in APIs, wire-formats, on-disk formats, etc.
> Are our wire formats stable enough in all release lines that we're ready to
> live by this?
No. Long-term we'd li
+1 on Matt's proposal.
On Wed, Nov 16, 2011 at 1:11 PM, Matt Foley wrote:
> I support giving all three active code branches a clean start, on an equal
> footing:
>
> - The next release of 0.20-security (formerly expected as "0.20.205.1") to
> be 1.0.0, establishing branch-1.0
> - The next release
How about this?
I have a vote running for 1.x at this point. We seem to agree about
major/minor/patch version and need for compatibility.
Beyond that, all other releases (at this point), whether it's 0.22 (unreleased)
or 0.23 (very alpha) are not worth debating endlessly.
Should we just revisi
On 11/16/11 4:43 PM, "Arun C Murthy" wrote:
> I propose we adopt the convention that a new major version should be a
> superset of the previous major version, features-wise.
Just so I'm clear. This is only guaranteed at the time the new major version is
started. A day later a previous major line
> On Wed, Nov 16, 2011 at 1:11 PM, Matt Foley wrote:
> I support giving all three active code branches a clean start, on an equal
> footing:
>
> - The next release of 0.20-security (formerly expected as
> "0.20.205.1") to be 1.0.0, establishing branch-1.0
> - The next release of 0.22 to be 2.
On Nov 16, 2011, at 3:02 PM, Doug Cutting wrote:
>
> Another definition is that a major release permits incompatible changes,
> either in APIs, wire-formats, on-disk formats, etc. This is more
> objective measure. For example, one might in release X+1 deprecate
> features of release X but still
Agreed.
We will discard features as we go along, but we need to have consensus to
discard major features. Is that fair?
And we discard them for reasons you outlined...
Arun
On Nov 16, 2011, at 3:02 PM, Doug Cutting wrote:
> On 11/16/2011 02:43 PM, Arun C Murthy wrote:
>> I propose we adopt th
On Wed, Nov 16, 2011 at 1:11 PM, Matt Foley wrote:
> I support giving all three active code branches a clean start, on an equal
> footing:
>
> - The next release of 0.20-security (formerly expected as "0.20.205.1") to
> be 1.0.0, establishing branch-1.0
> - The next release of 0.22 to be 2.0.0, es
On 11/16/2011 02:43 PM, Arun C Murthy wrote:
> I propose we adopt the convention that a new major version should be a
> superset of the previous major version, features-wise.
That means that we could never discard a feature, no?
One definition is that a major release includes some fundamental
ch
On Nov 16, 2011, at 11:57 AM, Doug Cutting wrote:
> On 11/16/2011 10:15 AM, Scott Carey wrote:
>> - Should hadoop adopt a new clear definition of major.minor.patch number
>> significance?
>
> Would you care to call a vote on one or both of these?
Great points Scott and Doug. I agree about the n
+1 to Owen's slight modification and to Matt's proposal with a minor (no
pun intended) suggestion
branch-0.20-security -> branch-1.0
branch-0.20-security-205 -> branch-1.1.0
On Wed, Nov 16, 2011 at 4:37 PM, Owen O'Malley wrote:
> +1 to Matt's proposal, although I'd modify it slightly to say tha
+1 to Matt's proposal, although I'd modify it slightly to say that:
branch-0.20-security -> branch-1
branch-0.20-security-205 -> branch-1.0
-- Owen
After a month's hiatus for Hadoop World, we're back! The December Hadoop
meetup will be held Wednesday, December 14, from 6pm to 8pm. This meetup
will be hosted by Splunk at their office on Brannan St.
As usual, we will use the discussion-based "unconference" format. At the
beginning of the meetup
I support giving all three active code branches a clean start, on an equal
footing:
- The next release of 0.20-security (formerly expected as "0.20.205.1") to
be 1.0.0, establishing branch-1.0
- The next release of 0.22 to be 2.0.0, establishing branch-2.0
- The recent release of 0.23.0 to be 3.0.
On 11/16/2011 10:15 AM, Scott Carey wrote:
> IMO what is important from the development and maintenance perspective is
> the _meaning_ of the
> major.minor.patch numbers as described in my previous message.
>
> If a minor version number bump means that it is a superset of the previous
> release an
The HBase-Writer team is happy to announce that HBase-Writer 0.90.3 is
available for download:
http://code.google.com/p/hbase-writer/downloads/list
HBase-Writer 0.90.3 is a maintenance release that fixes library
compatibility since older
versions of Heritrix and HBase. More details may be fou
On 11/16/11 9:24 AM, "Konstantin Boudnik" wrote:
>On Wed, Nov 16, 2011 at 09:15AM, Doug Cutting wrote:
>> On 11/15/2011 06:06 PM, Konstantin Boudnik wrote:
>> > Are you suggesting to drop 0.22 out of the picture all together? Any
>> > reason for that?
>>
>> By no means. I thought that we migh
On Wed, Nov 16, 2011 at 09:15AM, Doug Cutting wrote:
> On 11/15/2011 06:06 PM, Konstantin Boudnik wrote:
> > Are you suggesting to drop 0.22 out of the picture all together? Any
> > reason for that?
>
> By no means. I thought that we might, as Scott Carey said, treat 0.22
> as a minor release in
On 11/15/2011 06:06 PM, Konstantin Boudnik wrote:
> Are you suggesting to drop 0.22 out of the picture all together? Any
> reason for that?
By no means. I thought that we might, as Scott Carey said, treat 0.22
as a minor release in the 1.x series. I'd prefer that we consistently
rename branches
On Wed, Nov 16, 2011 at 10:22AM, Steve Loughran wrote:
> On 16/11/11 04:22, Arun Murthy wrote:
>> Please vote on naming 'future' releases off branch-0.20-security (with
>> both security& append) as hadoop-1.x.x.
>>
>> We should also rename branch-0.20-security as branch-1.x.x.
>>
>> I propose we u
A little wider perspective on where the renaming takes us and why it
is happening. My opinion.
Last year around this same time the Hadoop project was on the verge of
splitting.
We had three "commercial" versions of Hadoop competing to be the
"real" Hadoop, while the officially released Apache vers
On 16/11/11 07:38, Eric Baldeschwieler wrote:
In general terms, I think it is fair to expect that the project progresses, not
regresses between major versions. That said, major versions are major versions
and can change things.
which is precisely why I've voted for leaving the 0.20.x branche
On 16/11/11 04:22, Arun Murthy wrote:
Please vote on naming 'future' releases off branch-0.20-security (with
both security& append) as hadoop-1.x.x.
We should also rename branch-0.20-security as branch-1.x.x.
I propose we use the common 3-part major, minor (compatible, newer
features) and sub-
31 matches
Mail list logo
