You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flume.apache.org by Eric Sammer <es...@cloudera.com> on 2011/11/30 01:53:35 UTC
[DISCUSS] Flume NG alpha release
All:
I wanted to kick off a conversation around producing an alpha release of
the Flume NG branch. The goal would be to create a downloadable artifact
for people to test and play with without needing to build the project from
source. For lack of a better name, I'm proposing we call this
flume-1.0.0-alpha1. This isn't a formal vote, but a straw man discussion.
What do people think? Discuss!
Thanks!
--
Eric Sammer
twitter: esammer
data: www.cloudera.com
Re: [DISCUSS] Flume NG alpha release
Posted by Prasad Mujumdar <pr...@cloudera.com>.
+1
Please feel free to assign any task to me if you need.
thanks
Prasad
On Tue, Dec 20, 2011 at 9:25 PM, Eric Sammer <es...@cloudera.com> wrote:
> I'd like to volunteer to be the RM for the 1.0.0 release. I have an
> attachment to this first release (both of NG and since we joined the ASF)
> and would like to see it through.
>
> On Tue, Dec 20, 2011 at 4:17 PM, Arvind Prabhakar <ar...@apache.org>
> wrote:
>
> > On Tue, Dec 20, 2011 at 4:03 PM, Prasad Mujumdar <pr...@cloudera.com>
> > wrote:
> > > As next the step for 1.0 release preparation -
> > > 1) Move all the non-blocker Jiras to a new release version 1.0.1
> > > 2) Mark NG alpha 3 as released
> > > 3) The NG work will continue as 1.0.1 and trunk will be 0.9.5
> > >
> > > Please let me know if you are agree to the Jira changes.
> >
> > +1.
> >
> > One clarification - the release version will be 1.0.0, the release
> > type will be alpha.
> >
> > Thanks,
> > Arvind
> >
> >
> >
> > >
> > > thanks
> > > Prasad
> > >
> > >
> > > On Fri, Dec 2, 2011 at 1:17 PM, Eric Sammer <es...@cloudera.com>
> > wrote:
> > >
> > >> Thanks Patrick.
> > >>
> > >> To be clear(er) I was definitely not suggesting a binary only release.
> > Just
> > >> that it seems like we could reduce the barrier to initial testing and
> > >> feedback if we released a non-production ready version of the NG
> branch;
> > >> that's really what I was after.
> > >>
> > >> It sounds like the right thing to do is simply create a release of NG
> > and
> > >> be clear to users that it's an early release for testing.
> > >>
> > >> On Fri, Dec 2, 2011 at 11:11 AM, Patrick Hunt <ph...@apache.org>
> wrote:
> > >>
> > >> > On Fri, Dec 2, 2011 at 9:43 AM, Eric Sammer <es...@cloudera.com>
> > >> wrote:
> > >> > > Mentors, is there any other ASF connotation to calling something a
> > new
> > >> > > major version? I want to make sure I understand what I'm talking
> > >> > > about. ;)
> > >> >
> > >> > See this, anything else you do is up to you.
> > >> > http://www.apache.org/dev/release.html#what
> > >> >
> > >> > but to be overly clear the following statement is in error:
> > >> >
> > >> > > "The goal would be to create a downloadable artifact for people to
> > test
> > >> > and play with without needing to build the project from source"
> > >> >
> > >> > That is not your goal wrt Apache. Your goal is:
> > >> >
> > >> > "The Apache Software Foundation produces open source software. All
> > >> > releases are in the form of the source materials needed to make
> > >> > changes to the software being released."
> > >> > also
> > >> > "Under no circumstances are unapproved builds a substitute for
> > >> > releases. If this policy seems inconvenient, then release more
> often.
> > >> > Proper release management is a key aspect of Apache software
> > >> > development."
> > >> >
> > >> > If you want to also provide a convenience artifact (ie binary(s))
> > >> > along with the source release artifact that's fine, but that's not
> > >> > what you are "releasing".
> > >> >
> > >> > We face the same issue in ZK. We resolve it by releasing new
> official
> > >> > versions and just messaging what's stable vs beta vs alpha etc...
> > >> > That's what you have a web site for. Blogs, etc... We did the same
> > >> > thing in Whirr.
> > >> >
> > >> > Start creating & publishing releases often, that's the only way to
> get
> > >> > things into user's hands.
> > >> >
> > >> > Patrick
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Eric Sammer
> > >> twitter: esammer
> > >> data: www.cloudera.com
> > >>
> >
>
>
>
> --
> Eric Sammer
> twitter: esammer
> data: www.cloudera.com
>
Re: [DISCUSS] Flume NG alpha release
Posted by "arvind@cloudera.com" <ar...@cloudera.com>.
+1!
Go for it!
Thanks,
Arvind
On Tue, Dec 20, 2011 at 9:25 PM, Eric Sammer <es...@cloudera.com> wrote:
> I'd like to volunteer to be the RM for the 1.0.0 release. I have an
> attachment to this first release (both of NG and since we joined the ASF)
> and would like to see it through.
>
> On Tue, Dec 20, 2011 at 4:17 PM, Arvind Prabhakar <ar...@apache.org>
> wrote:
>
> > On Tue, Dec 20, 2011 at 4:03 PM, Prasad Mujumdar <pr...@cloudera.com>
> > wrote:
> > > As next the step for 1.0 release preparation -
> > > 1) Move all the non-blocker Jiras to a new release version 1.0.1
> > > 2) Mark NG alpha 3 as released
> > > 3) The NG work will continue as 1.0.1 and trunk will be 0.9.5
> > >
> > > Please let me know if you are agree to the Jira changes.
> >
> > +1.
> >
> > One clarification - the release version will be 1.0.0, the release
> > type will be alpha.
> >
> > Thanks,
> > Arvind
> >
> >
> >
> > >
> > > thanks
> > > Prasad
> > >
> > >
> > > On Fri, Dec 2, 2011 at 1:17 PM, Eric Sammer <es...@cloudera.com>
> > wrote:
> > >
> > >> Thanks Patrick.
> > >>
> > >> To be clear(er) I was definitely not suggesting a binary only release.
> > Just
> > >> that it seems like we could reduce the barrier to initial testing and
> > >> feedback if we released a non-production ready version of the NG
> branch;
> > >> that's really what I was after.
> > >>
> > >> It sounds like the right thing to do is simply create a release of NG
> > and
> > >> be clear to users that it's an early release for testing.
> > >>
> > >> On Fri, Dec 2, 2011 at 11:11 AM, Patrick Hunt <ph...@apache.org>
> wrote:
> > >>
> > >> > On Fri, Dec 2, 2011 at 9:43 AM, Eric Sammer <es...@cloudera.com>
> > >> wrote:
> > >> > > Mentors, is there any other ASF connotation to calling something a
> > new
> > >> > > major version? I want to make sure I understand what I'm talking
> > >> > > about. ;)
> > >> >
> > >> > See this, anything else you do is up to you.
> > >> > http://www.apache.org/dev/release.html#what
> > >> >
> > >> > but to be overly clear the following statement is in error:
> > >> >
> > >> > > "The goal would be to create a downloadable artifact for people to
> > test
> > >> > and play with without needing to build the project from source"
> > >> >
> > >> > That is not your goal wrt Apache. Your goal is:
> > >> >
> > >> > "The Apache Software Foundation produces open source software. All
> > >> > releases are in the form of the source materials needed to make
> > >> > changes to the software being released."
> > >> > also
> > >> > "Under no circumstances are unapproved builds a substitute for
> > >> > releases. If this policy seems inconvenient, then release more
> often.
> > >> > Proper release management is a key aspect of Apache software
> > >> > development."
> > >> >
> > >> > If you want to also provide a convenience artifact (ie binary(s))
> > >> > along with the source release artifact that's fine, but that's not
> > >> > what you are "releasing".
> > >> >
> > >> > We face the same issue in ZK. We resolve it by releasing new
> official
> > >> > versions and just messaging what's stable vs beta vs alpha etc...
> > >> > That's what you have a web site for. Blogs, etc... We did the same
> > >> > thing in Whirr.
> > >> >
> > >> > Start creating & publishing releases often, that's the only way to
> get
> > >> > things into user's hands.
> > >> >
> > >> > Patrick
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Eric Sammer
> > >> twitter: esammer
> > >> data: www.cloudera.com
> > >>
> >
>
>
>
> --
> Eric Sammer
> twitter: esammer
> data: www.cloudera.com
>
Re: [DISCUSS] Flume NG alpha release
Posted by Eric Sammer <es...@cloudera.com>.
I'd like to volunteer to be the RM for the 1.0.0 release. I have an
attachment to this first release (both of NG and since we joined the ASF)
and would like to see it through.
On Tue, Dec 20, 2011 at 4:17 PM, Arvind Prabhakar <ar...@apache.org> wrote:
> On Tue, Dec 20, 2011 at 4:03 PM, Prasad Mujumdar <pr...@cloudera.com>
> wrote:
> > As next the step for 1.0 release preparation -
> > 1) Move all the non-blocker Jiras to a new release version 1.0.1
> > 2) Mark NG alpha 3 as released
> > 3) The NG work will continue as 1.0.1 and trunk will be 0.9.5
> >
> > Please let me know if you are agree to the Jira changes.
>
> +1.
>
> One clarification - the release version will be 1.0.0, the release
> type will be alpha.
>
> Thanks,
> Arvind
>
>
>
> >
> > thanks
> > Prasad
> >
> >
> > On Fri, Dec 2, 2011 at 1:17 PM, Eric Sammer <es...@cloudera.com>
> wrote:
> >
> >> Thanks Patrick.
> >>
> >> To be clear(er) I was definitely not suggesting a binary only release.
> Just
> >> that it seems like we could reduce the barrier to initial testing and
> >> feedback if we released a non-production ready version of the NG branch;
> >> that's really what I was after.
> >>
> >> It sounds like the right thing to do is simply create a release of NG
> and
> >> be clear to users that it's an early release for testing.
> >>
> >> On Fri, Dec 2, 2011 at 11:11 AM, Patrick Hunt <ph...@apache.org> wrote:
> >>
> >> > On Fri, Dec 2, 2011 at 9:43 AM, Eric Sammer <es...@cloudera.com>
> >> wrote:
> >> > > Mentors, is there any other ASF connotation to calling something a
> new
> >> > > major version? I want to make sure I understand what I'm talking
> >> > > about. ;)
> >> >
> >> > See this, anything else you do is up to you.
> >> > http://www.apache.org/dev/release.html#what
> >> >
> >> > but to be overly clear the following statement is in error:
> >> >
> >> > > "The goal would be to create a downloadable artifact for people to
> test
> >> > and play with without needing to build the project from source"
> >> >
> >> > That is not your goal wrt Apache. Your goal is:
> >> >
> >> > "The Apache Software Foundation produces open source software. All
> >> > releases are in the form of the source materials needed to make
> >> > changes to the software being released."
> >> > also
> >> > "Under no circumstances are unapproved builds a substitute for
> >> > releases. If this policy seems inconvenient, then release more often.
> >> > Proper release management is a key aspect of Apache software
> >> > development."
> >> >
> >> > If you want to also provide a convenience artifact (ie binary(s))
> >> > along with the source release artifact that's fine, but that's not
> >> > what you are "releasing".
> >> >
> >> > We face the same issue in ZK. We resolve it by releasing new official
> >> > versions and just messaging what's stable vs beta vs alpha etc...
> >> > That's what you have a web site for. Blogs, etc... We did the same
> >> > thing in Whirr.
> >> >
> >> > Start creating & publishing releases often, that's the only way to get
> >> > things into user's hands.
> >> >
> >> > Patrick
> >> >
> >>
> >>
> >>
> >> --
> >> Eric Sammer
> >> twitter: esammer
> >> data: www.cloudera.com
> >>
>
--
Eric Sammer
twitter: esammer
data: www.cloudera.com
Re: [DISCUSS] Flume NG alpha release
Posted by Arvind Prabhakar <ar...@apache.org>.
On Tue, Dec 20, 2011 at 4:03 PM, Prasad Mujumdar <pr...@cloudera.com> wrote:
> As next the step for 1.0 release preparation -
> 1) Move all the non-blocker Jiras to a new release version 1.0.1
> 2) Mark NG alpha 3 as released
> 3) The NG work will continue as 1.0.1 and trunk will be 0.9.5
>
> Please let me know if you are agree to the Jira changes.
+1.
One clarification - the release version will be 1.0.0, the release
type will be alpha.
Thanks,
Arvind
>
> thanks
> Prasad
>
>
> On Fri, Dec 2, 2011 at 1:17 PM, Eric Sammer <es...@cloudera.com> wrote:
>
>> Thanks Patrick.
>>
>> To be clear(er) I was definitely not suggesting a binary only release. Just
>> that it seems like we could reduce the barrier to initial testing and
>> feedback if we released a non-production ready version of the NG branch;
>> that's really what I was after.
>>
>> It sounds like the right thing to do is simply create a release of NG and
>> be clear to users that it's an early release for testing.
>>
>> On Fri, Dec 2, 2011 at 11:11 AM, Patrick Hunt <ph...@apache.org> wrote:
>>
>> > On Fri, Dec 2, 2011 at 9:43 AM, Eric Sammer <es...@cloudera.com>
>> wrote:
>> > > Mentors, is there any other ASF connotation to calling something a new
>> > > major version? I want to make sure I understand what I'm talking
>> > > about. ;)
>> >
>> > See this, anything else you do is up to you.
>> > http://www.apache.org/dev/release.html#what
>> >
>> > but to be overly clear the following statement is in error:
>> >
>> > > "The goal would be to create a downloadable artifact for people to test
>> > and play with without needing to build the project from source"
>> >
>> > That is not your goal wrt Apache. Your goal is:
>> >
>> > "The Apache Software Foundation produces open source software. All
>> > releases are in the form of the source materials needed to make
>> > changes to the software being released."
>> > also
>> > "Under no circumstances are unapproved builds a substitute for
>> > releases. If this policy seems inconvenient, then release more often.
>> > Proper release management is a key aspect of Apache software
>> > development."
>> >
>> > If you want to also provide a convenience artifact (ie binary(s))
>> > along with the source release artifact that's fine, but that's not
>> > what you are "releasing".
>> >
>> > We face the same issue in ZK. We resolve it by releasing new official
>> > versions and just messaging what's stable vs beta vs alpha etc...
>> > That's what you have a web site for. Blogs, etc... We did the same
>> > thing in Whirr.
>> >
>> > Start creating & publishing releases often, that's the only way to get
>> > things into user's hands.
>> >
>> > Patrick
>> >
>>
>>
>>
>> --
>> Eric Sammer
>> twitter: esammer
>> data: www.cloudera.com
>>
Re: [DISCUSS] Flume NG alpha release
Posted by Prasad Mujumdar <pr...@cloudera.com>.
As next the step for 1.0 release preparation -
1) Move all the non-blocker Jiras to a new release version 1.0.1
2) Mark NG alpha 3 as released
3) The NG work will continue as 1.0.1 and trunk will be 0.9.5
Please let me know if you are agree to the Jira changes.
thanks
Prasad
On Fri, Dec 2, 2011 at 1:17 PM, Eric Sammer <es...@cloudera.com> wrote:
> Thanks Patrick.
>
> To be clear(er) I was definitely not suggesting a binary only release. Just
> that it seems like we could reduce the barrier to initial testing and
> feedback if we released a non-production ready version of the NG branch;
> that's really what I was after.
>
> It sounds like the right thing to do is simply create a release of NG and
> be clear to users that it's an early release for testing.
>
> On Fri, Dec 2, 2011 at 11:11 AM, Patrick Hunt <ph...@apache.org> wrote:
>
> > On Fri, Dec 2, 2011 at 9:43 AM, Eric Sammer <es...@cloudera.com>
> wrote:
> > > Mentors, is there any other ASF connotation to calling something a new
> > > major version? I want to make sure I understand what I'm talking
> > > about. ;)
> >
> > See this, anything else you do is up to you.
> > http://www.apache.org/dev/release.html#what
> >
> > but to be overly clear the following statement is in error:
> >
> > > "The goal would be to create a downloadable artifact for people to test
> > and play with without needing to build the project from source"
> >
> > That is not your goal wrt Apache. Your goal is:
> >
> > "The Apache Software Foundation produces open source software. All
> > releases are in the form of the source materials needed to make
> > changes to the software being released."
> > also
> > "Under no circumstances are unapproved builds a substitute for
> > releases. If this policy seems inconvenient, then release more often.
> > Proper release management is a key aspect of Apache software
> > development."
> >
> > If you want to also provide a convenience artifact (ie binary(s))
> > along with the source release artifact that's fine, but that's not
> > what you are "releasing".
> >
> > We face the same issue in ZK. We resolve it by releasing new official
> > versions and just messaging what's stable vs beta vs alpha etc...
> > That's what you have a web site for. Blogs, etc... We did the same
> > thing in Whirr.
> >
> > Start creating & publishing releases often, that's the only way to get
> > things into user's hands.
> >
> > Patrick
> >
>
>
>
> --
> Eric Sammer
> twitter: esammer
> data: www.cloudera.com
>
Re: [DISCUSS] Flume NG alpha release
Posted by Eric Sammer <es...@cloudera.com>.
Thanks Patrick.
To be clear(er) I was definitely not suggesting a binary only release. Just
that it seems like we could reduce the barrier to initial testing and
feedback if we released a non-production ready version of the NG branch;
that's really what I was after.
It sounds like the right thing to do is simply create a release of NG and
be clear to users that it's an early release for testing.
On Fri, Dec 2, 2011 at 11:11 AM, Patrick Hunt <ph...@apache.org> wrote:
> On Fri, Dec 2, 2011 at 9:43 AM, Eric Sammer <es...@cloudera.com> wrote:
> > Mentors, is there any other ASF connotation to calling something a new
> > major version? I want to make sure I understand what I'm talking
> > about. ;)
>
> See this, anything else you do is up to you.
> http://www.apache.org/dev/release.html#what
>
> but to be overly clear the following statement is in error:
>
> > "The goal would be to create a downloadable artifact for people to test
> and play with without needing to build the project from source"
>
> That is not your goal wrt Apache. Your goal is:
>
> "The Apache Software Foundation produces open source software. All
> releases are in the form of the source materials needed to make
> changes to the software being released."
> also
> "Under no circumstances are unapproved builds a substitute for
> releases. If this policy seems inconvenient, then release more often.
> Proper release management is a key aspect of Apache software
> development."
>
> If you want to also provide a convenience artifact (ie binary(s))
> along with the source release artifact that's fine, but that's not
> what you are "releasing".
>
> We face the same issue in ZK. We resolve it by releasing new official
> versions and just messaging what's stable vs beta vs alpha etc...
> That's what you have a web site for. Blogs, etc... We did the same
> thing in Whirr.
>
> Start creating & publishing releases often, that's the only way to get
> things into user's hands.
>
> Patrick
>
--
Eric Sammer
twitter: esammer
data: www.cloudera.com
Re: [DISCUSS] Flume NG alpha release
Posted by Patrick Hunt <ph...@apache.org>.
On Fri, Dec 2, 2011 at 9:43 AM, Eric Sammer <es...@cloudera.com> wrote:
> Mentors, is there any other ASF connotation to calling something a new
> major version? I want to make sure I understand what I'm talking
> about. ;)
See this, anything else you do is up to you.
http://www.apache.org/dev/release.html#what
but to be overly clear the following statement is in error:
> "The goal would be to create a downloadable artifact for people to test and play with without needing to build the project from source"
That is not your goal wrt Apache. Your goal is:
"The Apache Software Foundation produces open source software. All
releases are in the form of the source materials needed to make
changes to the software being released."
also
"Under no circumstances are unapproved builds a substitute for
releases. If this policy seems inconvenient, then release more often.
Proper release management is a key aspect of Apache software
development."
If you want to also provide a convenience artifact (ie binary(s))
along with the source release artifact that's fine, but that's not
what you are "releasing".
We face the same issue in ZK. We resolve it by releasing new official
versions and just messaging what's stable vs beta vs alpha etc...
That's what you have a web site for. Blogs, etc... We did the same
thing in Whirr.
Start creating & publishing releases often, that's the only way to get
things into user's hands.
Patrick
Re: [DISCUSS] Flume NG alpha release
Posted by Jonathan Hsieh <jo...@cloudera.com>.
Noted. I'm really +0 on the 1.0.0 designation.
I guess the main thing I'm concerned with is that we define the version
numbering story and stay consistent if possible. Its been rough going
deciphering versions in some other projects I've been involved with, and
we've been fast and loose with versioning some of our previous releases.
Jon.
On Fri, Dec 2, 2011 at 10:56 AM, ralph.goers @dslextreme.com <
ralph.goers@dslextreme.com> wrote:
> Version numbers are whatever you document them to be on your web site.
>
> You have already indicated that it will have an "alpha" designator on the
> release. To me, the determining factor on a number would be what will you
> want the release number to be once the "alpha" and/or "beta" designators
> come off. I wouldn't want to see a bunch of alphas and betas for the next
> year if that is how long you believe it would take to get a 1.0 GA release
> out.
>
> The concern I have with .10 is that it might connotate that this is just an
> incremental improvement over .9. Since neither of them have hit 1.0 I
> would hope there is no expectation that backward compatibility is
> guaranteed though.
>
> Ralph
>
> On Fri, Dec 2, 2011 at 9:43 AM, Eric Sammer <es...@cloudera.com> wrote:
>
> > I don't think 1.0 means feature complete (there's really no such thing
> > in an evolving project, only milestone complete) but it does make some
> > promises about feature stability. I do think ng's feature set is
> > stable in that it is maintainable and can act as the basis for future
> > expansion. A major version bump also means no backward incompatible
> > changes which I'm admittedly a little less sure of. I don't feel super
> > strong about the version number we use but I also don't want to be
> > 1.0-phobic either. I'm not against going 0.10 but I do want to
> > indicate this is significantly different than 0.9.x. Another way of
> > looking at it is to say that we've broken backward compat so we should
> > bump the major version.
> >
> > Mentors, is there any other ASF connotation to calling something a new
> > major version? I want to make sure I understand what I'm talking
> > about. ;)
> >
> > On Dec 2, 2011, at 8:45 AM, Jonathan Hsieh <jo...@cloudera.com> wrote:
> >
> > > Just throwing this out there, but other projects use 1.0 as an
> indicator
> > of
> > > feature completeness. Is that the implication we want to make by
> > labeling
> > > this as 1.0.0-xxx?
> > >
> > > I feel that a pre-1.0.0 number such as 0.10.0 might be more apt.
> > >
> > > Jon.
> > >
> > > On Fri, Dec 2, 2011 at 8:35 AM, Arvind Prabhakar <ar...@apache.org>
> > wrote:
> > >
> > >> The policy documents pointed out by Ralph states the following:
> > >>
> > >> <quote>
> > >> Releases that only represent a project milestone and are intended only
> > >> for bleeding-edge developers working outside the project are called
> > >> "alpha"
> > >> </quote>
> > >>
> > >> This is completely inline with where we are with the Flume NG branch
> > >> and would be an appropriate release artifact to help enable the
> > >> borader community to help test and validate its design.
> > >>
> > >> I am a strong +1 on going forward with the 1.0.0-alpha-1 release.
> > >>
> > >> Thanks,
> > >> Arvind
> > >>
> > >>
> > >> On Tue, Nov 29, 2011 at 10:57 PM, Ralph Goers
> > >> <ra...@dslextreme.com> wrote:
> > >>> Take a look at http://www.apache.org/dev/release.html#what as well
> as
> > >> the section that follows it. Releases are the only approved way of
> > >> delivering our software to end users. While we can suggest that they
> > check
> > >> it out from subversion and try it in practice that doesn't usually
> get a
> > >> lot of traction and it is a bit more difficult to report issues.
> > >>>
> > >>> I also recommend going through with the release as it is an important
> > >> step in moving through the incubator. It is expected that issues will
> > occur
> > >> during the release and having problems occur on an alpha release is
> > less of
> > >> a problem then on a GA release.
> > >>>
> > >>> In short, I highly recommend a release.
> > >>>
> > >>> Ralph
> > >>>
> > >>> On Nov 29, 2011, at 4:53 PM, Eric Sammer wrote:
> > >>>
> > >>>> All:
> > >>>>
> > >>>> I wanted to kick off a conversation around producing an alpha
> release
> > of
> > >>>> the Flume NG branch. The goal would be to create a downloadable
> > artifact
> > >>>> for people to test and play with without needing to build the
> project
> > >> from
> > >>>> source. For lack of a better name, I'm proposing we call this
> > >>>> flume-1.0.0-alpha1. This isn't a formal vote, but a straw man
> > >> discussion.
> > >>>> What do people think? Discuss!
> > >>>>
> > >>>> Thanks!
> > >>>> --
> > >>>> Eric Sammer
> > >>>> twitter: esammer
> > >>>> data: www.cloudera.com
> > >>>
> > >>
> > >
> > >
> > >
> > > --
> > > // Jonathan Hsieh (shay)
> > > // Software Engineer, Cloudera
> > > // jon@cloudera.com
> >
>
--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com
Re: [DISCUSS] Flume NG alpha release
Posted by "ralph.goers @dslextreme.com" <ra...@dslextreme.com>.
Version numbers are whatever you document them to be on your web site.
You have already indicated that it will have an "alpha" designator on the
release. To me, the determining factor on a number would be what will you
want the release number to be once the "alpha" and/or "beta" designators
come off. I wouldn't want to see a bunch of alphas and betas for the next
year if that is how long you believe it would take to get a 1.0 GA release
out.
The concern I have with .10 is that it might connotate that this is just an
incremental improvement over .9. Since neither of them have hit 1.0 I
would hope there is no expectation that backward compatibility is
guaranteed though.
Ralph
On Fri, Dec 2, 2011 at 9:43 AM, Eric Sammer <es...@cloudera.com> wrote:
> I don't think 1.0 means feature complete (there's really no such thing
> in an evolving project, only milestone complete) but it does make some
> promises about feature stability. I do think ng's feature set is
> stable in that it is maintainable and can act as the basis for future
> expansion. A major version bump also means no backward incompatible
> changes which I'm admittedly a little less sure of. I don't feel super
> strong about the version number we use but I also don't want to be
> 1.0-phobic either. I'm not against going 0.10 but I do want to
> indicate this is significantly different than 0.9.x. Another way of
> looking at it is to say that we've broken backward compat so we should
> bump the major version.
>
> Mentors, is there any other ASF connotation to calling something a new
> major version? I want to make sure I understand what I'm talking
> about. ;)
>
> On Dec 2, 2011, at 8:45 AM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
> > Just throwing this out there, but other projects use 1.0 as an indicator
> of
> > feature completeness. Is that the implication we want to make by
> labeling
> > this as 1.0.0-xxx?
> >
> > I feel that a pre-1.0.0 number such as 0.10.0 might be more apt.
> >
> > Jon.
> >
> > On Fri, Dec 2, 2011 at 8:35 AM, Arvind Prabhakar <ar...@apache.org>
> wrote:
> >
> >> The policy documents pointed out by Ralph states the following:
> >>
> >> <quote>
> >> Releases that only represent a project milestone and are intended only
> >> for bleeding-edge developers working outside the project are called
> >> "alpha"
> >> </quote>
> >>
> >> This is completely inline with where we are with the Flume NG branch
> >> and would be an appropriate release artifact to help enable the
> >> borader community to help test and validate its design.
> >>
> >> I am a strong +1 on going forward with the 1.0.0-alpha-1 release.
> >>
> >> Thanks,
> >> Arvind
> >>
> >>
> >> On Tue, Nov 29, 2011 at 10:57 PM, Ralph Goers
> >> <ra...@dslextreme.com> wrote:
> >>> Take a look at http://www.apache.org/dev/release.html#what as well as
> >> the section that follows it. Releases are the only approved way of
> >> delivering our software to end users. While we can suggest that they
> check
> >> it out from subversion and try it in practice that doesn't usually get a
> >> lot of traction and it is a bit more difficult to report issues.
> >>>
> >>> I also recommend going through with the release as it is an important
> >> step in moving through the incubator. It is expected that issues will
> occur
> >> during the release and having problems occur on an alpha release is
> less of
> >> a problem then on a GA release.
> >>>
> >>> In short, I highly recommend a release.
> >>>
> >>> Ralph
> >>>
> >>> On Nov 29, 2011, at 4:53 PM, Eric Sammer wrote:
> >>>
> >>>> All:
> >>>>
> >>>> I wanted to kick off a conversation around producing an alpha release
> of
> >>>> the Flume NG branch. The goal would be to create a downloadable
> artifact
> >>>> for people to test and play with without needing to build the project
> >> from
> >>>> source. For lack of a better name, I'm proposing we call this
> >>>> flume-1.0.0-alpha1. This isn't a formal vote, but a straw man
> >> discussion.
> >>>> What do people think? Discuss!
> >>>>
> >>>> Thanks!
> >>>> --
> >>>> Eric Sammer
> >>>> twitter: esammer
> >>>> data: www.cloudera.com
> >>>
> >>
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // Software Engineer, Cloudera
> > // jon@cloudera.com
>
Re: [DISCUSS] Flume NG alpha release
Posted by Eric Sammer <es...@cloudera.com>.
I don't think 1.0 means feature complete (there's really no such thing
in an evolving project, only milestone complete) but it does make some
promises about feature stability. I do think ng's feature set is
stable in that it is maintainable and can act as the basis for future
expansion. A major version bump also means no backward incompatible
changes which I'm admittedly a little less sure of. I don't feel super
strong about the version number we use but I also don't want to be
1.0-phobic either. I'm not against going 0.10 but I do want to
indicate this is significantly different than 0.9.x. Another way of
looking at it is to say that we've broken backward compat so we should
bump the major version.
Mentors, is there any other ASF connotation to calling something a new
major version? I want to make sure I understand what I'm talking
about. ;)
On Dec 2, 2011, at 8:45 AM, Jonathan Hsieh <jo...@cloudera.com> wrote:
> Just throwing this out there, but other projects use 1.0 as an indicator of
> feature completeness. Is that the implication we want to make by labeling
> this as 1.0.0-xxx?
>
> I feel that a pre-1.0.0 number such as 0.10.0 might be more apt.
>
> Jon.
>
> On Fri, Dec 2, 2011 at 8:35 AM, Arvind Prabhakar <ar...@apache.org> wrote:
>
>> The policy documents pointed out by Ralph states the following:
>>
>> <quote>
>> Releases that only represent a project milestone and are intended only
>> for bleeding-edge developers working outside the project are called
>> "alpha"
>> </quote>
>>
>> This is completely inline with where we are with the Flume NG branch
>> and would be an appropriate release artifact to help enable the
>> borader community to help test and validate its design.
>>
>> I am a strong +1 on going forward with the 1.0.0-alpha-1 release.
>>
>> Thanks,
>> Arvind
>>
>>
>> On Tue, Nov 29, 2011 at 10:57 PM, Ralph Goers
>> <ra...@dslextreme.com> wrote:
>>> Take a look at http://www.apache.org/dev/release.html#what as well as
>> the section that follows it. Releases are the only approved way of
>> delivering our software to end users. While we can suggest that they check
>> it out from subversion and try it in practice that doesn't usually get a
>> lot of traction and it is a bit more difficult to report issues.
>>>
>>> I also recommend going through with the release as it is an important
>> step in moving through the incubator. It is expected that issues will occur
>> during the release and having problems occur on an alpha release is less of
>> a problem then on a GA release.
>>>
>>> In short, I highly recommend a release.
>>>
>>> Ralph
>>>
>>> On Nov 29, 2011, at 4:53 PM, Eric Sammer wrote:
>>>
>>>> All:
>>>>
>>>> I wanted to kick off a conversation around producing an alpha release of
>>>> the Flume NG branch. The goal would be to create a downloadable artifact
>>>> for people to test and play with without needing to build the project
>> from
>>>> source. For lack of a better name, I'm proposing we call this
>>>> flume-1.0.0-alpha1. This isn't a formal vote, but a straw man
>> discussion.
>>>> What do people think? Discuss!
>>>>
>>>> Thanks!
>>>> --
>>>> Eric Sammer
>>>> twitter: esammer
>>>> data: www.cloudera.com
>>>
>>
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
Re: [DISCUSS] Flume NG alpha release
Posted by Jonathan Hsieh <jo...@cloudera.com>.
Just throwing this out there, but other projects use 1.0 as an indicator of
feature completeness. Is that the implication we want to make by labeling
this as 1.0.0-xxx?
I feel that a pre-1.0.0 number such as 0.10.0 might be more apt.
Jon.
On Fri, Dec 2, 2011 at 8:35 AM, Arvind Prabhakar <ar...@apache.org> wrote:
> The policy documents pointed out by Ralph states the following:
>
> <quote>
> Releases that only represent a project milestone and are intended only
> for bleeding-edge developers working outside the project are called
> "alpha"
> </quote>
>
> This is completely inline with where we are with the Flume NG branch
> and would be an appropriate release artifact to help enable the
> borader community to help test and validate its design.
>
> I am a strong +1 on going forward with the 1.0.0-alpha-1 release.
>
> Thanks,
> Arvind
>
>
> On Tue, Nov 29, 2011 at 10:57 PM, Ralph Goers
> <ra...@dslextreme.com> wrote:
> > Take a look at http://www.apache.org/dev/release.html#what as well as
> the section that follows it. Releases are the only approved way of
> delivering our software to end users. While we can suggest that they check
> it out from subversion and try it in practice that doesn't usually get a
> lot of traction and it is a bit more difficult to report issues.
> >
> > I also recommend going through with the release as it is an important
> step in moving through the incubator. It is expected that issues will occur
> during the release and having problems occur on an alpha release is less of
> a problem then on a GA release.
> >
> > In short, I highly recommend a release.
> >
> > Ralph
> >
> > On Nov 29, 2011, at 4:53 PM, Eric Sammer wrote:
> >
> >> All:
> >>
> >> I wanted to kick off a conversation around producing an alpha release of
> >> the Flume NG branch. The goal would be to create a downloadable artifact
> >> for people to test and play with without needing to build the project
> from
> >> source. For lack of a better name, I'm proposing we call this
> >> flume-1.0.0-alpha1. This isn't a formal vote, but a straw man
> discussion.
> >> What do people think? Discuss!
> >>
> >> Thanks!
> >> --
> >> Eric Sammer
> >> twitter: esammer
> >> data: www.cloudera.com
> >
>
--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com
Re: [DISCUSS] Flume NG alpha release
Posted by Arvind Prabhakar <ar...@apache.org>.
The policy documents pointed out by Ralph states the following:
<quote>
Releases that only represent a project milestone and are intended only
for bleeding-edge developers working outside the project are called
"alpha"
</quote>
This is completely inline with where we are with the Flume NG branch
and would be an appropriate release artifact to help enable the
borader community to help test and validate its design.
I am a strong +1 on going forward with the 1.0.0-alpha-1 release.
Thanks,
Arvind
On Tue, Nov 29, 2011 at 10:57 PM, Ralph Goers
<ra...@dslextreme.com> wrote:
> Take a look at http://www.apache.org/dev/release.html#what as well as the section that follows it. Releases are the only approved way of delivering our software to end users. While we can suggest that they check it out from subversion and try it in practice that doesn't usually get a lot of traction and it is a bit more difficult to report issues.
>
> I also recommend going through with the release as it is an important step in moving through the incubator. It is expected that issues will occur during the release and having problems occur on an alpha release is less of a problem then on a GA release.
>
> In short, I highly recommend a release.
>
> Ralph
>
> On Nov 29, 2011, at 4:53 PM, Eric Sammer wrote:
>
>> All:
>>
>> I wanted to kick off a conversation around producing an alpha release of
>> the Flume NG branch. The goal would be to create a downloadable artifact
>> for people to test and play with without needing to build the project from
>> source. For lack of a better name, I'm proposing we call this
>> flume-1.0.0-alpha1. This isn't a formal vote, but a straw man discussion.
>> What do people think? Discuss!
>>
>> Thanks!
>> --
>> Eric Sammer
>> twitter: esammer
>> data: www.cloudera.com
>
Re: [DISCUSS] Flume NG alpha release
Posted by Ralph Goers <ra...@dslextreme.com>.
Take a look at http://www.apache.org/dev/release.html#what as well as the section that follows it. Releases are the only approved way of delivering our software to end users. While we can suggest that they check it out from subversion and try it in practice that doesn't usually get a lot of traction and it is a bit more difficult to report issues.
I also recommend going through with the release as it is an important step in moving through the incubator. It is expected that issues will occur during the release and having problems occur on an alpha release is less of a problem then on a GA release.
In short, I highly recommend a release.
Ralph
On Nov 29, 2011, at 4:53 PM, Eric Sammer wrote:
> All:
>
> I wanted to kick off a conversation around producing an alpha release of
> the Flume NG branch. The goal would be to create a downloadable artifact
> for people to test and play with without needing to build the project from
> source. For lack of a better name, I'm proposing we call this
> flume-1.0.0-alpha1. This isn't a formal vote, but a straw man discussion.
> What do people think? Discuss!
>
> Thanks!
> --
> Eric Sammer
> twitter: esammer
> data: www.cloudera.com