On Mon, Feb 4, 2013 at 2:14 PM, Suresh Srinivas wrote:
> On Mon, Feb 4, 2013 at 1:07 PM, Owen O'Malley wrote:
>
> > I think that using "-(alpha,beta)" tags on the release versions is a
> really
> > bad idea.
>
>
> Why? Can you please share some reasons?
>
>
We already had a means for denoting 'al
disclaimer, personal opinions only, I just can't be bothered to subscribe
with @apache.org right now.
On 4 February 2013 14:36, Todd Lipcon wrote:
> - Quality/completeness: for example, missing docs, buggy UIs, difficult
> setup/install, etc
>
par for the course. Have you ever used Linux?
> -
On Mon, Feb 4, 2013 at 2:14 PM, Suresh Srinivas wrote:
>
> Why? Can you please share some reasons?
>
> I actually think alpha and beta and stable/GA are much better way to set
> the expectation
> of the quality of a release. This has been practiced in software release
> cycle for a long time.
> Ha
On Mon, Feb 4, 2013 at 1:07 PM, Owen O'Malley wrote:
> I think that using "-(alpha,beta)" tags on the release versions is a really
> bad idea.
Why? Can you please share some reasons?
I actually think alpha and beta and stable/GA are much better way to set
the expectation
of the quality of a re
I think that using "-(alpha,beta)" tags on the release versions is a really
bad idea. All releases should follow the strictly numeric
(Major.Minor.Patch) pattern that we've used for all of the releases except
the 2.0.x ones.
-- Owen
On Mon, Feb 4, 2013 at 11:53 AM, Stack wrote:
> On Mon, Feb 4
On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy wrote:
> Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> stable release? This way we just have one series (2.0.x) which is not
> suitable for general consumption.
>
>
That contains the versioning damage to the 2.0.x set. Th
On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy wrote:
>
> On Feb 1, 2013, at 2:34 AM, Tom White wrote:
> > Whereas Arun is proposing
> >
> > 2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.1.0-alpha, 2.2.0-beta, 2.3.0
> >
> > and the casual observer might expect there to be a stable 2.0.1 (say)
> > on
On Feb 1, 2013, at 2:34 AM, Tom White wrote:
> Whereas Arun is proposing
>
> 2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.1.0-alpha, 2.2.0-beta, 2.3.0
>
> and the casual observer might expect there to be a stable 2.0.1 (say)
> on seeing the existence of 2.0.2-alpha.
>
> The first three of these ar
On Fri, Feb 1, 2013 at 3:03 AM, Tom White wrote:
> On Wed, Jan 30, 2013 at 11:32 PM, Vinod Kumar Vavilapalli
> wrote:
> > I still have a list of pending API/protocol cleanup in YARN that need to
> be
> > in before we even attempt supporting compatibility further down the road.
>
>
YARN requires
On Thu, Jan 31, 2013 at 12:12 PM, Arun C Murthy wrote:
> I apologize if there was too much technical details.
>
> The simplified version is that hadoop-2 isn't baked as it stands today,
> and is not viable to be supported by this community in a stable manner. In
> particular, it is due to the mov
On Fri, Feb 1, 2013 at 2:34 AM, Tom White wrote:
> Possibly the reason for Stack's consternation is that this is a
> Hadoop-specific versioning scheme, rather than a standard one like
> Semantic Versioning (http://semver.org/) which is more widely
> understood.
If I can offer an alternate and l
On Wed, Jan 30, 2013 at 11:32 PM, Vinod Kumar Vavilapalli
wrote:
> I still have a list of pending API/protocol cleanup in YARN that need to be
> in before we even attempt supporting compatibility further down the road.
To let others track these it would be useful if they were tagged in
JIRA with
Possibly the reason for Stack's consternation is that this is a
Hadoop-specific versioning scheme, rather than a standard one like
Semantic Versioning (http://semver.org/) which is more widely
understood.
With that scheme we would have something like
2.0.0-alpha, 2.0.0-alpha.1, 2.0.0-alpha.2, 2
Stack,
On Jan 30, 2013, at 9:25 PM, Stack wrote:
> I find the above opaque and written in a cryptic language that I might grok
> if I spent a day or two running over cited issues trying to make some
> distillation of the esotericia debated therein. If you want feedback from
> other than the cogn
We also need to spell out what's permissible *before* GA as well. The
alpha/beta labels, as I understand them, are not green lights to break
anything as long as it's not API compatibility. The API compatibility
story has been somewhat fuzzy as well, eg MR2 requires users recompile all
their Hadoo
On Tue, Jan 29, 2013 at 12:56 PM, Arun C Murthy wrote:
> Folks,
>
> There has been some discussions about incompatible changes in the
> hadoop-2.x.x-alpha releases on HADOOP-9070, HADOOP-9151, HADOOP-9192 and
> few other jiras. Frankly, I'm surprised about some of them since the
> 'alpha' monike
The discussions in HADOOP-9151 were related to wire-compatibility. I think we
all agree that breaking API compatibility is not allowed without deprecating
them first in a prior major release - this is something we have followed since
hadoop-0.1.
I agree we need to spell out what changes we can
Thanks for bringing this up Arun. One of the issues is that we
haven't been clear about what type of compatibility breakages are
allowed, and which are not. For example, renaming FileSystem#open is
incompatible, and not OK, regardless of the alpha/beta tag. Breaking
a server/server APIs is OK pr
I still have a list of pending API/protocol cleanup in YARN that need to be
in before we even attempt supporting compatibility further down the road.
There's no way we can support wire compatibility with the APIs in the state
that they are in now. So, +1 for a beta sometime in March.
There are som
Thanks Suresh. Adding back other *-dev lists.
On Jan 29, 2013, at 1:58 PM, Suresh Srinivas wrote:
> +1 for a release with all the changes that are committed. That way it
> carries all the important bug fixes.
>
>
> So, rather than debate more, I had a brief chat with Suresh and Todd. Todd
>> su
Folks,
There has been some discussions about incompatible changes in the
hadoop-2.x.x-alpha releases on HADOOP-9070, HADOOP-9151, HADOOP-9192 and few
other jiras. Frankly, I'm surprised about some of them since the 'alpha'
moniker was precisely to harden apis by changing them if necessary, bor
21 matches
Mail list logo
