You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flume.apache.org by Arvind Prabhakar <ar...@apache.org> on 2012/03/13 05:59:02 UTC
Preparing for Flume 1.1.0
Hi,
Since the release of version 1.0.0-incubating of Flume, we have made
significant progress in terms of development. Also of significance is
the fact that we have promoted the active development branch to trunk.
We are now technically ready to graduate as a top-level project (TLP).
To ensure that we do not get bogged down by various concerns that
people have expressed in the graduation of other projects, it is
prudent on our part to make a release from the trunk.
For this reason, I am proposing myself to be the release manager for
the upcoming release - version 1.1.0-incubating. The goal of this
release will be to create a distribution from the trunk where all
sources are in the expected org.apache.* namespace. It will also have
significantly more features and bug fixes than the previous release.
In order to bootstrap the process, I will go ahead and create the
release branch right away. If during the discussion on this thread we
feel that the release must contain certain patches not part of this
branch, I will be happy to port them over to the release branch if
they are committed to the trunk.
Thanks,
Arvind Prabhakar
Re: Preparing for Flume 1.1.0
Posted by Patrick Hunt <ph...@apache.org>.
also this incubator doc I just found:
http://incubator.apache.org/guides/releasemanagement.html#naming
On Tue, Mar 13, 2012 at 4:55 PM, Patrick Hunt <ph...@apache.org> wrote:
> On Tue, Mar 13, 2012 at 4:31 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> On Mar 13, 2012, at 4:08 PM, Eric Sammer wrote:
>>
>>> +1 on Arvind as 1.1.0 RM and on a 1.1.0 branch. +0 on labeling the release
>>> beta. Kind of feel like it's something to list in the README (on advice
>>> from phunt) and just release. Otherwise, it sounds like there will be a
>>> 1.1.0 final (which the ASF doesn't do). The advice I got when we tackled
>>> this with 1.0.0 was that the ASF produces releases, period. The quality can
>>> be indicated in the README (unless I misunderstood).
>>
>> I'm not sure whose advice you got but other projects do versions like 1.2-beta all the time. IMO opinion labeling this 1.1-beta-incubating makes it clear to everyone what it is even without reading the README, including anyone typing the version in their pom - who almost never read those.
>
> A couple good items on the faq about this, see this for general
> details on what's a release:
> http://www.apache.org/dev/release.html#what
>
> Also this which goes into a bit more detail about types of releases:
> http://www.apache.org/dev/release.html#release-typeso
>
> In neither of these cases is Apache proscribing how to "name" your
> release however (although in the incubator you must indicate clearly
> "incubating"). Just the process that must be followed to consider
> something a release.
>
> My personal experience (granted it's with Hadoop related projects) is
> that they typically do not include the quality level in the name
> itself. Rather putting it in the readme, release notes, etc... But
> that's up to you. Some projects at Apache certainly do this, but none
> that i've been involved with. My personal preference is to have
> release notes that cover any issues the user should be aware of,
> rather than relying on "alpha/beta" labels in the name which might be
> confusing.
>
> Patrick
Re: Preparing for Flume 1.1.0
Posted by alo alt <wg...@googlemail.com>.
+1 for the pointing to MC. That would be the best approach for us.
just my2cent,
Alex
--
Alexander Lorenz
http://mapredit.blogspot.com
On Mar 19, 2012, at 8:06 AM, Ralph Goers wrote:
>
> On Mar 18, 2012, at 11:58 PM, Arvind Prabhakar wrote:
>
>> On Sun, Mar 18, 2012 at 11:24 PM, Ralph Goers
>> <ra...@dslextreme.com> wrote:
>>>
>>> On Mar 18, 2012, at 9:32 PM, Arvind Prabhakar wrote:
>>>
>>>> We have already made a lesser stable release (version
>>>> 1.0.0-incubating) that was labeled as alpha in the RELEASE-NOTES file
>>>> that accompanied it.
>>>
>>> Yes - and not putting -alpha in the version was a mistake.
>>>
>>>> From this thread, I see that the consensus is to
>>>> call the 1.1.0 release a beta.
>>>>
>>>> I would therefore like to proceed with the release, with the official
>>>> version 1.1.0-incubating, and specifically labeled as "beta" in the
>>>> release notes. Since we are not calling it a 1.1.0-incubating-stable
>>>> or 1.1.0-incubating-GA, we do not risk implying the stability or
>>>> correctness of the released artifacts.
>>>
>>> Please, please, please go look at Maven Central. Rarely will you find 1.1.0-GA (User's dislike that immensely). But you will find tons of 1.1.0-beta1, 1.1.0-beta2, etc. The way people expect this is that we would have had a 1.0.0-alpha1, 1.0.0-alpha2 and then 1.0.0-beta1, 1.0.0-beta2. We didn't do that. We should start now. When it is considered not to be a beta then 1.1.0 should be released.
>>
>> I have no objections to doing the work if we have consensus or policy
>> that guides it. The opinion on this thread is split and I do not want
>> to chose one over the other. Hence am following what has been done in
>> the project before.
>>
>>>
>>> I'm having a hard time understanding why you really want to do this so differently than what the vast majority of other projects do.
>>
>> For the reasons stated above - lack of consensus or guiding policy.
>> Since you feel very strongly about this, I suggest you help establish
>> a policy by calling a vote on this. My only request to you would be to
>> not block this release waiting for the policy to be established.
>
> Sure - as an example of an existing policy you can look at http://commons.apache.org/releases/versioning.html#Release_Numbers.
>
> Release votes can't be vetoed so one person cannot block them. I would only vote -1 if I found something wrong with the release such as a missing notice or license. However, I might vote -0.5 on something like this.
>
> Ralph
Re: Preparing for Flume 1.1.0
Posted by Ralph Goers <ra...@dslextreme.com>.
On Mar 18, 2012, at 11:58 PM, Arvind Prabhakar wrote:
> On Sun, Mar 18, 2012 at 11:24 PM, Ralph Goers
> <ra...@dslextreme.com> wrote:
>>
>> On Mar 18, 2012, at 9:32 PM, Arvind Prabhakar wrote:
>>
>>> We have already made a lesser stable release (version
>>> 1.0.0-incubating) that was labeled as alpha in the RELEASE-NOTES file
>>> that accompanied it.
>>
>> Yes - and not putting -alpha in the version was a mistake.
>>
>>> From this thread, I see that the consensus is to
>>> call the 1.1.0 release a beta.
>>>
>>> I would therefore like to proceed with the release, with the official
>>> version 1.1.0-incubating, and specifically labeled as "beta" in the
>>> release notes. Since we are not calling it a 1.1.0-incubating-stable
>>> or 1.1.0-incubating-GA, we do not risk implying the stability or
>>> correctness of the released artifacts.
>>
>> Please, please, please go look at Maven Central. Rarely will you find 1.1.0-GA (User's dislike that immensely). But you will find tons of 1.1.0-beta1, 1.1.0-beta2, etc. The way people expect this is that we would have had a 1.0.0-alpha1, 1.0.0-alpha2 and then 1.0.0-beta1, 1.0.0-beta2. We didn't do that. We should start now. When it is considered not to be a beta then 1.1.0 should be released.
>
> I have no objections to doing the work if we have consensus or policy
> that guides it. The opinion on this thread is split and I do not want
> to chose one over the other. Hence am following what has been done in
> the project before.
>
>>
>> I'm having a hard time understanding why you really want to do this so differently than what the vast majority of other projects do.
>
> For the reasons stated above - lack of consensus or guiding policy.
> Since you feel very strongly about this, I suggest you help establish
> a policy by calling a vote on this. My only request to you would be to
> not block this release waiting for the policy to be established.
Sure - as an example of an existing policy you can look at http://commons.apache.org/releases/versioning.html#Release_Numbers.
Release votes can't be vetoed so one person cannot block them. I would only vote -1 if I found something wrong with the release such as a missing notice or license. However, I might vote -0.5 on something like this.
Ralph
Re: Preparing for Flume 1.1.0
Posted by Arvind Prabhakar <ar...@apache.org>.
On Sun, Mar 18, 2012 at 11:24 PM, Ralph Goers
<ra...@dslextreme.com> wrote:
>
> On Mar 18, 2012, at 9:32 PM, Arvind Prabhakar wrote:
>
>> We have already made a lesser stable release (version
>> 1.0.0-incubating) that was labeled as alpha in the RELEASE-NOTES file
>> that accompanied it.
>
> Yes - and not putting -alpha in the version was a mistake.
>
>> From this thread, I see that the consensus is to
>> call the 1.1.0 release a beta.
>>
>> I would therefore like to proceed with the release, with the official
>> version 1.1.0-incubating, and specifically labeled as "beta" in the
>> release notes. Since we are not calling it a 1.1.0-incubating-stable
>> or 1.1.0-incubating-GA, we do not risk implying the stability or
>> correctness of the released artifacts.
>
> Please, please, please go look at Maven Central. Rarely will you find 1.1.0-GA (User's dislike that immensely). But you will find tons of 1.1.0-beta1, 1.1.0-beta2, etc. The way people expect this is that we would have had a 1.0.0-alpha1, 1.0.0-alpha2 and then 1.0.0-beta1, 1.0.0-beta2. We didn't do that. We should start now. When it is considered not to be a beta then 1.1.0 should be released.
I have no objections to doing the work if we have consensus or policy
that guides it. The opinion on this thread is split and I do not want
to chose one over the other. Hence am following what has been done in
the project before.
>
> I'm having a hard time understanding why you really want to do this so differently than what the vast majority of other projects do.
For the reasons stated above - lack of consensus or guiding policy.
Since you feel very strongly about this, I suggest you help establish
a policy by calling a vote on this. My only request to you would be to
not block this release waiting for the policy to be established.
Thanks,
Arvind
>
> Ralph
>
Re: Preparing for Flume 1.1.0
Posted by Ralph Goers <ra...@dslextreme.com>.
On Mar 18, 2012, at 9:32 PM, Arvind Prabhakar wrote:
> We have already made a lesser stable release (version
> 1.0.0-incubating) that was labeled as alpha in the RELEASE-NOTES file
> that accompanied it.
Yes - and not putting -alpha in the version was a mistake.
> From this thread, I see that the consensus is to
> call the 1.1.0 release a beta.
>
> I would therefore like to proceed with the release, with the official
> version 1.1.0-incubating, and specifically labeled as "beta" in the
> release notes. Since we are not calling it a 1.1.0-incubating-stable
> or 1.1.0-incubating-GA, we do not risk implying the stability or
> correctness of the released artifacts.
Please, please, please go look at Maven Central. Rarely will you find 1.1.0-GA (User's dislike that immensely). But you will find tons of 1.1.0-beta1, 1.1.0-beta2, etc. The way people expect this is that we would have had a 1.0.0-alpha1, 1.0.0-alpha2 and then 1.0.0-beta1, 1.0.0-beta2. We didn't do that. We should start now. When it is considered not to be a beta then 1.1.0 should be released.
I'm having a hard time understanding why you really want to do this so differently than what the vast majority of other projects do.
Ralph
Re: Preparing for Flume 1.1.0
Posted by Arvind Prabhakar <ar...@apache.org>.
We have already made a lesser stable release (version
1.0.0-incubating) that was labeled as alpha in the RELEASE-NOTES file
that accompanied it. From this thread, I see that the consensus is to
call the 1.1.0 release a beta.
I would therefore like to proceed with the release, with the official
version 1.1.0-incubating, and specifically labeled as "beta" in the
release notes. Since we are not calling it a 1.1.0-incubating-stable
or 1.1.0-incubating-GA, we do not risk implying the stability or
correctness of the released artifacts.
Thanks,
Arvind Prabhakar
On Sun, Mar 18, 2012 at 7:56 PM, Juhani Connolly
<ju...@cyberagent.co.jp> wrote:
> On 03/17/2012 05:13 AM, Ralph Goers wrote:
>>
>> I actually don't see consensus, but I also don't think this discussion
>> should drag on. Just be prepared for user confusion, although it is hard to
>> determine how many user's there actually are.
>>
>> Ralph
>
>
> I wasn't going to mention it but since Ralph did: user confusion is
> definitely a bad thing and that "beta" probably should be in the file
> name... What reasons are there for it not being there? If we want to get
> more users to try it, having those too lazy to read the readme file is not
> going to make people more amenable to trying future release.
>
> I think regular releases are good, but we have to be honest with users what
> they're getting into. Most people don't give any piece of software more than
> one chance and if people aren't prepared to deal with some bugs and
> incomplete features they should probably wait till a later version to try
> flume ng. A clear filename would help avoid that confusion.
>
>
>> On Mar 16, 2012, at 10:19 AM, Arvind Prabhakar<ar...@apache.org> wrote:
>>
>>> Thanks Juhani and Jarcec for your input.
>>>
>>> From the thread it appears that we have a consensus on the following:
>>>
>>> Version: 1.1.0-incubating
>>> Release Label: beta, as specified in the README file.
>>>
>>> Thanks,
>>> Arvind Prabhakar
>>>
>>> On Fri, Mar 16, 2012 at 1:09 AM, Jarek Jarcec Cecho<ja...@apache.org>
>>> wrote:
>>>>
>>>> I personally do not feel the need to put "beta" directly into version
>>>> name. However I agree with Juhani that this release should be marked as
>>>> "beta" quality at least in documentation or release notes with a list of
>>>> known issues if possible (for example FLUME-862, ...).
>>>>
>>>> Just my 2 cents worth,
>>>> Jarcec
>>>>
>>>> On Fri, Mar 16, 2012 at 10:36:11AM +0900, Juhani Connolly wrote:
>>>>>
>>>>> On 03/16/2012 02:22 AM, Arvind Prabhakar wrote:
>>>>>>
>>>>>> On Tue, Mar 13, 2012 at 10:33 PM, Ralph Goers
>>>>>> <ra...@dslextreme.com> wrote:
>>>>>>>
>>>>>>> On Mar 13, 2012, at 9:34 PM, Patrick Hunt wrote:
>>>>>>>
>>>>>>>> On Tue, Mar 13, 2012 at 5:59 PM, Ralph
>>>>>>>> Goers<ra...@dslextreme.com> wrote:
>>>>>>>>>
>>>>>>>>> In Maven we do this all the time, both for Maven itself and the
>>>>>>>>> plugins. I recall doing it for Cocoon.
>>>>>>>>>
>>>>>>>>> http://archive.apache.org/dist/tomcat/tomcat-7/
>>>>>>>>> http://archive.apache.org/dist/httpd/
>>>>>>>>> http://archive.apache.org/dist/httpcomponents/httpclient/binary/
>>>>>>>>> http://archive.apache.org/dist/commons/lang/binaries/ (Notice that
>>>>>>>>> 3.0, which broke compatibility, had a beta)
>>>>>>>>> http://archive.apache.org/dist/jackrabbit/
>>>>>>>>>
>>>>>>>>> In fact, I would say it is more the norm to do this than not.
>>>>>>>>>
>>>>>>>>> Again, I'm used to dealing with Maven users. They will assume that
>>>>>>>>> if it doesn't have alpha or beta in the version then it isn't one.
>>>>>>>>
>>>>>>>> Seems a reasonable approach. How do you decide what is alpha vs what
>>>>>>>> is beta vs a regular release? is there some special implication of
>>>>>>>> alpha vs beta?
>>>>>>>
>>>>>>> That is exactly why I started off this conversation with "The only
>>>>>>> question I have is whether the community considers this release "stable" or
>>>>>>> "ready for production" use". It isn't so much a question of missing
>>>>>>> features, although that may be important, but whether it provides the
>>>>>>> minimum functionality to actually be used in production and there are no
>>>>>>> blocking bugs. If the PMC feels it isn't beta quality then don't call it
>>>>>>> one. But if it is it should be labeled as such. The difference between alpha
>>>>>>> and beta is simply a matter of how far the project feels the code is from
>>>>>>> being production ready. For example, an alpha release will usually contain
>>>>>>> something that gives an idea of the direction but isn't very usable. Beta
>>>>>>> software frequently can be used but no one is very confident in it. I guess
>>>>>>> the real question to ask is, if you had a business to run with your
>>>>>>> customers relying on your software would you be comfortable using it\? If
>>>>>>> the answer is no then it should be an alpha or beta release. As engineers
>>>>>>> many of us are never completely comfortable with people using our software
>>>>>>> for fear something might break. We need to get over that.
>>>>>
>>>>> Fwiw, we are currently using scribed for our log collection on
>>>>> production servers. We want to use flume NG but do not feel
>>>>> comfortable running it in production yet. Considering what Ralph
>>>>> said, for that reason personally I think this should be considered a
>>>>> beta release, and think that any documentation should encourage
>>>>> early adopters to try it, but believe that people mistakenly
>>>>> believing it is a stable release is going to cause a lot of pain
>>>>> to users as they figure out which features work properly and which
>>>>> don't.
>>>>>
>>>>>>> I guess in this case I would say are we at the point where we are
>>>>>>> recommending that Flume users use NG instead of OG. (It has to be one or the
>>>>>>> other). If the answer is NG then I don't think it should be a beta. If you
>>>>>>> want them to try NG but still rely on OG then it should be a beta.
>>>>>>>
>>>>>> Thanks Ralph. Since no objections have be raised, I feel that we are
>>>>>> in agreement regarding the naming of this release. Specifically, we
>>>>>> don't want to label it as beta and would like to encourage users to
>>>>>> adopt it in favor of the prior 0.9.x release.
>>>>>>
>>>>>>> Mind you, this criteria is just my opinion. Everyone is free to judge
>>>>>>> the code for themselves but this can be handled in 1 of 2 ways. 1) The
>>>>>>> project (i.e. PMC) decides, 2) The release manager makes the decision. In
>>>>>>> most communities he who does the work gets to make the decision but the PMC
>>>>>>> is responsible for the release so, of course, has the right to make the
>>>>>>> call.
>>>>>>>
>>>>>> For now I will proceed with calling this version 1.1.0-incubating. If
>>>>>> there is disagreement, we can call a vote to settle. Note that I am
>>>>>> actively working on the release so any disagreement will have to be
>>>>>> resolved soon.
>>>>>>
>>>>>> Thanks,
>>>>>> Arvind Prabhakar
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>
>
Re: Preparing for Flume 1.1.0
Posted by Juhani Connolly <ju...@cyberagent.co.jp>.
On 03/17/2012 05:13 AM, Ralph Goers wrote:
> I actually don't see consensus, but I also don't think this discussion should drag on. Just be prepared for user confusion, although it is hard to determine how many user's there actually are.
>
> Ralph
I wasn't going to mention it but since Ralph did: user confusion is
definitely a bad thing and that "beta" probably should be in the file
name... What reasons are there for it not being there? If we want to get
more users to try it, having those too lazy to read the readme file is
not going to make people more amenable to trying future release.
I think regular releases are good, but we have to be honest with users
what they're getting into. Most people don't give any piece of software
more than one chance and if people aren't prepared to deal with some
bugs and incomplete features they should probably wait till a later
version to try flume ng. A clear filename would help avoid that confusion.
> On Mar 16, 2012, at 10:19 AM, Arvind Prabhakar<ar...@apache.org> wrote:
>
>> Thanks Juhani and Jarcec for your input.
>>
>> From the thread it appears that we have a consensus on the following:
>>
>> Version: 1.1.0-incubating
>> Release Label: beta, as specified in the README file.
>>
>> Thanks,
>> Arvind Prabhakar
>>
>> On Fri, Mar 16, 2012 at 1:09 AM, Jarek Jarcec Cecho<ja...@apache.org> wrote:
>>> I personally do not feel the need to put "beta" directly into version name. However I agree with Juhani that this release should be marked as "beta" quality at least in documentation or release notes with a list of known issues if possible (for example FLUME-862, ...).
>>>
>>> Just my 2 cents worth,
>>> Jarcec
>>>
>>> On Fri, Mar 16, 2012 at 10:36:11AM +0900, Juhani Connolly wrote:
>>>> On 03/16/2012 02:22 AM, Arvind Prabhakar wrote:
>>>>> On Tue, Mar 13, 2012 at 10:33 PM, Ralph Goers
>>>>> <ra...@dslextreme.com> wrote:
>>>>>> On Mar 13, 2012, at 9:34 PM, Patrick Hunt wrote:
>>>>>>
>>>>>>> On Tue, Mar 13, 2012 at 5:59 PM, Ralph Goers<ra...@dslextreme.com> wrote:
>>>>>>>> In Maven we do this all the time, both for Maven itself and the plugins. I recall doing it for Cocoon.
>>>>>>>>
>>>>>>>> http://archive.apache.org/dist/tomcat/tomcat-7/
>>>>>>>> http://archive.apache.org/dist/httpd/
>>>>>>>> http://archive.apache.org/dist/httpcomponents/httpclient/binary/
>>>>>>>> http://archive.apache.org/dist/commons/lang/binaries/ (Notice that 3.0, which broke compatibility, had a beta)
>>>>>>>> http://archive.apache.org/dist/jackrabbit/
>>>>>>>>
>>>>>>>> In fact, I would say it is more the norm to do this than not.
>>>>>>>>
>>>>>>>> Again, I'm used to dealing with Maven users. They will assume that if it doesn't have alpha or beta in the version then it isn't one.
>>>>>>> Seems a reasonable approach. How do you decide what is alpha vs what
>>>>>>> is beta vs a regular release? is there some special implication of
>>>>>>> alpha vs beta?
>>>>>> That is exactly why I started off this conversation with "The only question I have is whether the community considers this release "stable" or "ready for production" use". It isn't so much a question of missing features, although that may be important, but whether it provides the minimum functionality to actually be used in production and there are no blocking bugs. If the PMC feels it isn't beta quality then don't call it one. But if it is it should be labeled as such. The difference between alpha and beta is simply a matter of how far the project feels the code is from being production ready. For example, an alpha release will usually contain something that gives an idea of the direction but isn't very usable. Beta software frequently can be used but no one is very confident in it. I guess the real question to ask is, if you had a business to run with your customers relying on your software would you be comfortable using it\? If the answer is no then it should be an alpha or beta release. As engineers many of us are never completely comfortable with people using our software for fear something might break. We need to get over that.
>>>> Fwiw, we are currently using scribed for our log collection on
>>>> production servers. We want to use flume NG but do not feel
>>>> comfortable running it in production yet. Considering what Ralph
>>>> said, for that reason personally I think this should be considered a
>>>> beta release, and think that any documentation should encourage
>>>> early adopters to try it, but believe that people mistakenly
>>>> believing it is a stable release is going to cause a lot of pain
>>>> to users as they figure out which features work properly and which
>>>> don't.
>>>>
>>>>>> I guess in this case I would say are we at the point where we are recommending that Flume users use NG instead of OG. (It has to be one or the other). If the answer is NG then I don't think it should be a beta. If you want them to try NG but still rely on OG then it should be a beta.
>>>>>>
>>>>> Thanks Ralph. Since no objections have be raised, I feel that we are
>>>>> in agreement regarding the naming of this release. Specifically, we
>>>>> don't want to label it as beta and would like to encourage users to
>>>>> adopt it in favor of the prior 0.9.x release.
>>>>>
>>>>>> Mind you, this criteria is just my opinion. Everyone is free to judge the code for themselves but this can be handled in 1 of 2 ways. 1) The project (i.e. PMC) decides, 2) The release manager makes the decision. In most communities he who does the work gets to make the decision but the PMC is responsible for the release so, of course, has the right to make the call.
>>>>>>
>>>>> For now I will proceed with calling this version 1.1.0-incubating. If
>>>>> there is disagreement, we can call a vote to settle. Note that I am
>>>>> actively working on the release so any disagreement will have to be
>>>>> resolved soon.
>>>>>
>>>>> Thanks,
>>>>> Arvind Prabhakar
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
Re: Preparing for Flume 1.1.0
Posted by Ralph Goers <rg...@apache.org>.
I actually don't see consensus, but I also don't think this discussion should drag on. Just be prepared for user confusion, although it is hard to determine how many user's there actually are.
Ralph
On Mar 16, 2012, at 10:19 AM, Arvind Prabhakar <ar...@apache.org> wrote:
> Thanks Juhani and Jarcec for your input.
>
> From the thread it appears that we have a consensus on the following:
>
> Version: 1.1.0-incubating
> Release Label: beta, as specified in the README file.
>
> Thanks,
> Arvind Prabhakar
>
> On Fri, Mar 16, 2012 at 1:09 AM, Jarek Jarcec Cecho <ja...@apache.org> wrote:
>> I personally do not feel the need to put "beta" directly into version name. However I agree with Juhani that this release should be marked as "beta" quality at least in documentation or release notes with a list of known issues if possible (for example FLUME-862, ...).
>>
>> Just my 2 cents worth,
>> Jarcec
>>
>> On Fri, Mar 16, 2012 at 10:36:11AM +0900, Juhani Connolly wrote:
>>> On 03/16/2012 02:22 AM, Arvind Prabhakar wrote:
>>>> On Tue, Mar 13, 2012 at 10:33 PM, Ralph Goers
>>>> <ra...@dslextreme.com> wrote:
>>>>> On Mar 13, 2012, at 9:34 PM, Patrick Hunt wrote:
>>>>>
>>>>>> On Tue, Mar 13, 2012 at 5:59 PM, Ralph Goers<ra...@dslextreme.com> wrote:
>>>>>>> In Maven we do this all the time, both for Maven itself and the plugins. I recall doing it for Cocoon.
>>>>>>>
>>>>>>> http://archive.apache.org/dist/tomcat/tomcat-7/
>>>>>>> http://archive.apache.org/dist/httpd/
>>>>>>> http://archive.apache.org/dist/httpcomponents/httpclient/binary/
>>>>>>> http://archive.apache.org/dist/commons/lang/binaries/ (Notice that 3.0, which broke compatibility, had a beta)
>>>>>>> http://archive.apache.org/dist/jackrabbit/
>>>>>>>
>>>>>>> In fact, I would say it is more the norm to do this than not.
>>>>>>>
>>>>>>> Again, I'm used to dealing with Maven users. They will assume that if it doesn't have alpha or beta in the version then it isn't one.
>>>>>> Seems a reasonable approach. How do you decide what is alpha vs what
>>>>>> is beta vs a regular release? is there some special implication of
>>>>>> alpha vs beta?
>>>>> That is exactly why I started off this conversation with "The only question I have is whether the community considers this release "stable" or "ready for production" use". It isn't so much a question of missing features, although that may be important, but whether it provides the minimum functionality to actually be used in production and there are no blocking bugs. If the PMC feels it isn't beta quality then don't call it one. But if it is it should be labeled as such. The difference between alpha and beta is simply a matter of how far the project feels the code is from being production ready. For example, an alpha release will usually contain something that gives an idea of the direction but isn't very usable. Beta software frequently can be used but no one is very confident in it. I guess the real question to ask is, if you had a business to run with your customers relying on your software would you be comfortable using it\? If the answer is no then it should be an alpha or beta release. As engineers many of us are never completely comfortable with people using our software for fear something might break. We need to get over that.
>>> Fwiw, we are currently using scribed for our log collection on
>>> production servers. We want to use flume NG but do not feel
>>> comfortable running it in production yet. Considering what Ralph
>>> said, for that reason personally I think this should be considered a
>>> beta release, and think that any documentation should encourage
>>> early adopters to try it, but believe that people mistakenly
>>> believing it is a stable release is going to cause a lot of pain
>>> to users as they figure out which features work properly and which
>>> don't.
>>>
>>>>> I guess in this case I would say are we at the point where we are recommending that Flume users use NG instead of OG. (It has to be one or the other). If the answer is NG then I don't think it should be a beta. If you want them to try NG but still rely on OG then it should be a beta.
>>>>>
>>>> Thanks Ralph. Since no objections have be raised, I feel that we are
>>>> in agreement regarding the naming of this release. Specifically, we
>>>> don't want to label it as beta and would like to encourage users to
>>>> adopt it in favor of the prior 0.9.x release.
>>>>
>>>>> Mind you, this criteria is just my opinion. Everyone is free to judge the code for themselves but this can be handled in 1 of 2 ways. 1) The project (i.e. PMC) decides, 2) The release manager makes the decision. In most communities he who does the work gets to make the decision but the PMC is responsible for the release so, of course, has the right to make the call.
>>>>>
>>>> For now I will proceed with calling this version 1.1.0-incubating. If
>>>> there is disagreement, we can call a vote to settle. Note that I am
>>>> actively working on the release so any disagreement will have to be
>>>> resolved soon.
>>>>
>>>> Thanks,
>>>> Arvind Prabhakar
>>>>
>>>>
>>>>
>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
Re: Preparing for Flume 1.1.0
Posted by Arvind Prabhakar <ar...@apache.org>.
Thanks Juhani and Jarcec for your input.
>From the thread it appears that we have a consensus on the following:
Version: 1.1.0-incubating
Release Label: beta, as specified in the README file.
Thanks,
Arvind Prabhakar
On Fri, Mar 16, 2012 at 1:09 AM, Jarek Jarcec Cecho <ja...@apache.org> wrote:
> I personally do not feel the need to put "beta" directly into version name. However I agree with Juhani that this release should be marked as "beta" quality at least in documentation or release notes with a list of known issues if possible (for example FLUME-862, ...).
>
> Just my 2 cents worth,
> Jarcec
>
> On Fri, Mar 16, 2012 at 10:36:11AM +0900, Juhani Connolly wrote:
>> On 03/16/2012 02:22 AM, Arvind Prabhakar wrote:
>> >On Tue, Mar 13, 2012 at 10:33 PM, Ralph Goers
>> ><ra...@dslextreme.com> wrote:
>> >>On Mar 13, 2012, at 9:34 PM, Patrick Hunt wrote:
>> >>
>> >>>On Tue, Mar 13, 2012 at 5:59 PM, Ralph Goers<ra...@dslextreme.com> wrote:
>> >>>>In Maven we do this all the time, both for Maven itself and the plugins. I recall doing it for Cocoon.
>> >>>>
>> >>>>http://archive.apache.org/dist/tomcat/tomcat-7/
>> >>>>http://archive.apache.org/dist/httpd/
>> >>>>http://archive.apache.org/dist/httpcomponents/httpclient/binary/
>> >>>>http://archive.apache.org/dist/commons/lang/binaries/ (Notice that 3.0, which broke compatibility, had a beta)
>> >>>>http://archive.apache.org/dist/jackrabbit/
>> >>>>
>> >>>>In fact, I would say it is more the norm to do this than not.
>> >>>>
>> >>>>Again, I'm used to dealing with Maven users. They will assume that if it doesn't have alpha or beta in the version then it isn't one.
>> >>>Seems a reasonable approach. How do you decide what is alpha vs what
>> >>>is beta vs a regular release? is there some special implication of
>> >>>alpha vs beta?
>> >>That is exactly why I started off this conversation with "The only question I have is whether the community considers this release "stable" or "ready for production" use". It isn't so much a question of missing features, although that may be important, but whether it provides the minimum functionality to actually be used in production and there are no blocking bugs. If the PMC feels it isn't beta quality then don't call it one. But if it is it should be labeled as such. The difference between alpha and beta is simply a matter of how far the project feels the code is from being production ready. For example, an alpha release will usually contain something that gives an idea of the direction but isn't very usable. Beta software frequently can be used but no one is very confident in it. I guess the real question to ask is, if you had a business to run with your customers relying on your software would you be comfortable using it\? If the answer is no then it should be an alpha or beta release. As engineers many of us are never completely comfortable with people using our software for fear something might break. We need to get over that.
>> Fwiw, we are currently using scribed for our log collection on
>> production servers. We want to use flume NG but do not feel
>> comfortable running it in production yet. Considering what Ralph
>> said, for that reason personally I think this should be considered a
>> beta release, and think that any documentation should encourage
>> early adopters to try it, but believe that people mistakenly
>> believing it is a stable release is going to cause a lot of pain
>> to users as they figure out which features work properly and which
>> don't.
>>
>> >>I guess in this case I would say are we at the point where we are recommending that Flume users use NG instead of OG. (It has to be one or the other). If the answer is NG then I don't think it should be a beta. If you want them to try NG but still rely on OG then it should be a beta.
>> >>
>> >Thanks Ralph. Since no objections have be raised, I feel that we are
>> >in agreement regarding the naming of this release. Specifically, we
>> >don't want to label it as beta and would like to encourage users to
>> >adopt it in favor of the prior 0.9.x release.
>> >
>> >>Mind you, this criteria is just my opinion. Everyone is free to judge the code for themselves but this can be handled in 1 of 2 ways. 1) The project (i.e. PMC) decides, 2) The release manager makes the decision. In most communities he who does the work gets to make the decision but the PMC is responsible for the release so, of course, has the right to make the call.
>> >>
>> >For now I will proceed with calling this version 1.1.0-incubating. If
>> >there is disagreement, we can call a vote to settle. Note that I am
>> >actively working on the release so any disagreement will have to be
>> >resolved soon.
>> >
>> >Thanks,
>> >Arvind Prabhakar
>> >
>> >
>> >
>> >
>> >>Ralph
>> >>
>> >>
>> >>
>> >>
>>
>>
Re: Preparing for Flume 1.1.0
Posted by Jarek Jarcec Cecho <ja...@apache.org>.
I personally do not feel the need to put "beta" directly into version name. However I agree with Juhani that this release should be marked as "beta" quality at least in documentation or release notes with a list of known issues if possible (for example FLUME-862, ...).
Just my 2 cents worth,
Jarcec
On Fri, Mar 16, 2012 at 10:36:11AM +0900, Juhani Connolly wrote:
> On 03/16/2012 02:22 AM, Arvind Prabhakar wrote:
> >On Tue, Mar 13, 2012 at 10:33 PM, Ralph Goers
> ><ra...@dslextreme.com> wrote:
> >>On Mar 13, 2012, at 9:34 PM, Patrick Hunt wrote:
> >>
> >>>On Tue, Mar 13, 2012 at 5:59 PM, Ralph Goers<ra...@dslextreme.com> wrote:
> >>>>In Maven we do this all the time, both for Maven itself and the plugins. I recall doing it for Cocoon.
> >>>>
> >>>>http://archive.apache.org/dist/tomcat/tomcat-7/
> >>>>http://archive.apache.org/dist/httpd/
> >>>>http://archive.apache.org/dist/httpcomponents/httpclient/binary/
> >>>>http://archive.apache.org/dist/commons/lang/binaries/ (Notice that 3.0, which broke compatibility, had a beta)
> >>>>http://archive.apache.org/dist/jackrabbit/
> >>>>
> >>>>In fact, I would say it is more the norm to do this than not.
> >>>>
> >>>>Again, I'm used to dealing with Maven users. They will assume that if it doesn't have alpha or beta in the version then it isn't one.
> >>>Seems a reasonable approach. How do you decide what is alpha vs what
> >>>is beta vs a regular release? is there some special implication of
> >>>alpha vs beta?
> >>That is exactly why I started off this conversation with "The only question I have is whether the community considers this release "stable" or "ready for production" use". It isn't so much a question of missing features, although that may be important, but whether it provides the minimum functionality to actually be used in production and there are no blocking bugs. If the PMC feels it isn't beta quality then don't call it one. But if it is it should be labeled as such. The difference between alpha and beta is simply a matter of how far the project feels the code is from being production ready. For example, an alpha release will usually contain something that gives an idea of the direction but isn't very usable. Beta software frequently can be used but no one is very confident in it. I guess the real question to ask is, if you had a business to run with your customers relying on your software would you be comfortable using it\? If the answer is no then it should be an alpha or beta release. As engineers many of us are never completely comfortable with people using our software for fear something might break. We need to get over that.
> Fwiw, we are currently using scribed for our log collection on
> production servers. We want to use flume NG but do not feel
> comfortable running it in production yet. Considering what Ralph
> said, for that reason personally I think this should be considered a
> beta release, and think that any documentation should encourage
> early adopters to try it, but believe that people mistakenly
> believing it is a stable release is going to cause a lot of pain
> to users as they figure out which features work properly and which
> don't.
>
> >>I guess in this case I would say are we at the point where we are recommending that Flume users use NG instead of OG. (It has to be one or the other). If the answer is NG then I don't think it should be a beta. If you want them to try NG but still rely on OG then it should be a beta.
> >>
> >Thanks Ralph. Since no objections have be raised, I feel that we are
> >in agreement regarding the naming of this release. Specifically, we
> >don't want to label it as beta and would like to encourage users to
> >adopt it in favor of the prior 0.9.x release.
> >
> >>Mind you, this criteria is just my opinion. Everyone is free to judge the code for themselves but this can be handled in 1 of 2 ways. 1) The project (i.e. PMC) decides, 2) The release manager makes the decision. In most communities he who does the work gets to make the decision but the PMC is responsible for the release so, of course, has the right to make the call.
> >>
> >For now I will proceed with calling this version 1.1.0-incubating. If
> >there is disagreement, we can call a vote to settle. Note that I am
> >actively working on the release so any disagreement will have to be
> >resolved soon.
> >
> >Thanks,
> >Arvind Prabhakar
> >
> >
> >
> >
> >>Ralph
> >>
> >>
> >>
> >>
>
>
Re: Preparing for Flume 1.1.0
Posted by Juhani Connolly <ju...@cyberagent.co.jp>.
On 03/16/2012 02:22 AM, Arvind Prabhakar wrote:
> On Tue, Mar 13, 2012 at 10:33 PM, Ralph Goers
> <ra...@dslextreme.com> wrote:
>> On Mar 13, 2012, at 9:34 PM, Patrick Hunt wrote:
>>
>>> On Tue, Mar 13, 2012 at 5:59 PM, Ralph Goers<ra...@dslextreme.com> wrote:
>>>> In Maven we do this all the time, both for Maven itself and the plugins. I recall doing it for Cocoon.
>>>>
>>>> http://archive.apache.org/dist/tomcat/tomcat-7/
>>>> http://archive.apache.org/dist/httpd/
>>>> http://archive.apache.org/dist/httpcomponents/httpclient/binary/
>>>> http://archive.apache.org/dist/commons/lang/binaries/ (Notice that 3.0, which broke compatibility, had a beta)
>>>> http://archive.apache.org/dist/jackrabbit/
>>>>
>>>> In fact, I would say it is more the norm to do this than not.
>>>>
>>>> Again, I'm used to dealing with Maven users. They will assume that if it doesn't have alpha or beta in the version then it isn't one.
>>> Seems a reasonable approach. How do you decide what is alpha vs what
>>> is beta vs a regular release? is there some special implication of
>>> alpha vs beta?
>> That is exactly why I started off this conversation with "The only question I have is whether the community considers this release "stable" or "ready for production" use". It isn't so much a question of missing features, although that may be important, but whether it provides the minimum functionality to actually be used in production and there are no blocking bugs. If the PMC feels it isn't beta quality then don't call it one. But if it is it should be labeled as such. The difference between alpha and beta is simply a matter of how far the project feels the code is from being production ready. For example, an alpha release will usually contain something that gives an idea of the direction but isn't very usable. Beta software frequently can be used but no one is very confident in it. I guess the real question to ask is, if you had a business to run with your customers relying on your software would you be comfortable using it\? If the answer is no then it should be an alpha or beta release. As engineers many of us are never completely comfortable with people using our software for fear something might break. We need to get over that.
Fwiw, we are currently using scribed for our log collection on
production servers. We want to use flume NG but do not feel comfortable
running it in production yet. Considering what Ralph said, for that
reason personally I think this should be considered a beta release, and
think that any documentation should encourage early adopters to try it,
but believe that people mistakenly believing it is a stable release is
going to cause a lot of pain to users as they figure out which features
work properly and which don't.
>> I guess in this case I would say are we at the point where we are recommending that Flume users use NG instead of OG. (It has to be one or the other). If the answer is NG then I don't think it should be a beta. If you want them to try NG but still rely on OG then it should be a beta.
>>
> Thanks Ralph. Since no objections have be raised, I feel that we are
> in agreement regarding the naming of this release. Specifically, we
> don't want to label it as beta and would like to encourage users to
> adopt it in favor of the prior 0.9.x release.
>
>> Mind you, this criteria is just my opinion. Everyone is free to judge the code for themselves but this can be handled in 1 of 2 ways. 1) The project (i.e. PMC) decides, 2) The release manager makes the decision. In most communities he who does the work gets to make the decision but the PMC is responsible for the release so, of course, has the right to make the call.
>>
> For now I will proceed with calling this version 1.1.0-incubating. If
> there is disagreement, we can call a vote to settle. Note that I am
> actively working on the release so any disagreement will have to be
> resolved soon.
>
> Thanks,
> Arvind Prabhakar
>
>
>
>
>> Ralph
>>
>>
>>
>>
Re: Preparing for Flume 1.1.0
Posted by Arvind Prabhakar <ar...@apache.org>.
On Tue, Mar 13, 2012 at 10:33 PM, Ralph Goers
<ra...@dslextreme.com> wrote:
>
> On Mar 13, 2012, at 9:34 PM, Patrick Hunt wrote:
>
>> On Tue, Mar 13, 2012 at 5:59 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>> In Maven we do this all the time, both for Maven itself and the plugins. I recall doing it for Cocoon.
>>>
>>> http://archive.apache.org/dist/tomcat/tomcat-7/
>>> http://archive.apache.org/dist/httpd/
>>> http://archive.apache.org/dist/httpcomponents/httpclient/binary/
>>> http://archive.apache.org/dist/commons/lang/binaries/ (Notice that 3.0, which broke compatibility, had a beta)
>>> http://archive.apache.org/dist/jackrabbit/
>>>
>>> In fact, I would say it is more the norm to do this than not.
>>>
>>> Again, I'm used to dealing with Maven users. They will assume that if it doesn't have alpha or beta in the version then it isn't one.
>>
>> Seems a reasonable approach. How do you decide what is alpha vs what
>> is beta vs a regular release? is there some special implication of
>> alpha vs beta?
>
> That is exactly why I started off this conversation with "The only question I have is whether the community considers this release "stable" or "ready for production" use". It isn't so much a question of missing features, although that may be important, but whether it provides the minimum functionality to actually be used in production and there are no blocking bugs. If the PMC feels it isn't beta quality then don't call it one. But if it is it should be labeled as such. The difference between alpha and beta is simply a matter of how far the project feels the code is from being production ready. For example, an alpha release will usually contain something that gives an idea of the direction but isn't very usable. Beta software frequently can be used but no one is very confident in it. I guess the real question to ask is, if you had a business to run with your customers relying on your software would you be comfortable using it\? If the answer is no then it should be an alpha or beta release. As engineers many of us are never completely comfortable with people using our software for fear something might break. We need to get over that.
>
> I guess in this case I would say are we at the point where we are recommending that Flume users use NG instead of OG. (It has to be one or the other). If the answer is NG then I don't think it should be a beta. If you want them to try NG but still rely on OG then it should be a beta.
>
Thanks Ralph. Since no objections have be raised, I feel that we are
in agreement regarding the naming of this release. Specifically, we
don't want to label it as beta and would like to encourage users to
adopt it in favor of the prior 0.9.x release.
> Mind you, this criteria is just my opinion. Everyone is free to judge the code for themselves but this can be handled in 1 of 2 ways. 1) The project (i.e. PMC) decides, 2) The release manager makes the decision. In most communities he who does the work gets to make the decision but the PMC is responsible for the release so, of course, has the right to make the call.
>
For now I will proceed with calling this version 1.1.0-incubating. If
there is disagreement, we can call a vote to settle. Note that I am
actively working on the release so any disagreement will have to be
resolved soon.
Thanks,
Arvind Prabhakar
> Ralph
>
>
>
>
Re: Preparing for Flume 1.1.0
Posted by Ralph Goers <ra...@dslextreme.com>.
On Mar 13, 2012, at 9:34 PM, Patrick Hunt wrote:
> On Tue, Mar 13, 2012 at 5:59 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> In Maven we do this all the time, both for Maven itself and the plugins. I recall doing it for Cocoon.
>>
>> http://archive.apache.org/dist/tomcat/tomcat-7/
>> http://archive.apache.org/dist/httpd/
>> http://archive.apache.org/dist/httpcomponents/httpclient/binary/
>> http://archive.apache.org/dist/commons/lang/binaries/ (Notice that 3.0, which broke compatibility, had a beta)
>> http://archive.apache.org/dist/jackrabbit/
>>
>> In fact, I would say it is more the norm to do this than not.
>>
>> Again, I'm used to dealing with Maven users. They will assume that if it doesn't have alpha or beta in the version then it isn't one.
>
> Seems a reasonable approach. How do you decide what is alpha vs what
> is beta vs a regular release? is there some special implication of
> alpha vs beta?
That is exactly why I started off this conversation with "The only question I have is whether the community considers this release "stable" or "ready for production" use". It isn't so much a question of missing features, although that may be important, but whether it provides the minimum functionality to actually be used in production and there are no blocking bugs. If the PMC feels it isn't beta quality then don't call it one. But if it is it should be labeled as such. The difference between alpha and beta is simply a matter of how far the project feels the code is from being production ready. For example, an alpha release will usually contain something that gives an idea of the direction but isn't very usable. Beta software frequently can be used but no one is very confident in it. I guess the real question to ask is, if you had a business to run with your customers relying on your software would you be comfortable using it\? If the answer is no then it should be an alpha or beta release. As engineers many of us are never completely comfortable with people using our software for fear something might break. We need to get over that.
I guess in this case I would say are we at the point where we are recommending that Flume users use NG instead of OG. (It has to be one or the other). If the answer is NG then I don't think it should be a beta. If you want them to try NG but still rely on OG then it should be a beta.
Mind you, this criteria is just my opinion. Everyone is free to judge the code for themselves but this can be handled in 1 of 2 ways. 1) The project (i.e. PMC) decides, 2) The release manager makes the decision. In most communities he who does the work gets to make the decision but the PMC is responsible for the release so, of course, has the right to make the call.
Ralph
Re: Preparing for Flume 1.1.0
Posted by Patrick Hunt <ph...@apache.org>.
On Tue, Mar 13, 2012 at 5:59 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Mar 13, 2012, at 4:55 PM, Patrick Hunt wrote:
>
>> On Tue, Mar 13, 2012 at 4:31 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>> On Mar 13, 2012, at 4:08 PM, Eric Sammer wrote:
>>>
>>>> +1 on Arvind as 1.1.0 RM and on a 1.1.0 branch. +0 on labeling the release
>>>> beta. Kind of feel like it's something to list in the README (on advice
>>>> from phunt) and just release. Otherwise, it sounds like there will be a
>>>> 1.1.0 final (which the ASF doesn't do). The advice I got when we tackled
>>>> this with 1.0.0 was that the ASF produces releases, period. The quality can
>>>> be indicated in the README (unless I misunderstood).
>>>
>>> I'm not sure whose advice you got but other projects do versions like 1.2-beta all the time. IMO opinion labeling this 1.1-beta-incubating makes it clear to everyone what it is even without reading the README, including anyone typing the version in their pom - who almost never read those.
>>
>> A couple good items on the faq about this, see this for general
>> details on what's a release:
>> http://www.apache.org/dev/release.html#what
>
> You didn't see this paragraph in the link above?
>
> Releases are packages that have been approved for general public release, with varying degrees of caveat regarding their perceived quality or potential for change. Releases that are intended for everyday usage by non-developers are usually referred to as "stable" or "general availability (GA)" releases. Releases that are believed to be usable by testers and developers outside the project, but perhaps not yet stable in terms of features or functionality, are usually referred to as "beta" or "unstable". Releases that only represent a project milestone and are intended only for bleeding-edge developers working outside the project are called "alpha".
>
> While this doesn't mean you have to include the terms in the name but I read that as certainly implying it.
>
I did see that, however I've found that Apache docs typically are
explicit if there are explicit requirements. otw the community is
enabled to do as they see fit.
>>
>> Also this which goes into a bit more detail about types of releases:
>> http://www.apache.org/dev/release.html#release-typeso
>>
>> In neither of these cases is Apache proscribing how to "name" your
>> release however (although in the incubator you must indicate clearly
>> "incubating"). Just the process that must be followed to consider
>> something a release.
>>
>> My personal experience (granted it's with Hadoop related projects) is
>> that they typically do not include the quality level in the name
>> itself. Rather putting it in the readme, release notes, etc... But
>> that's up to you. Some projects at Apache certainly do this, but none
>> that i've been involved with. My personal preference is to have
>> release notes that cover any issues the user should be aware of,
>> rather than relying on "alpha/beta" labels in the name which might be
>> confusing.
>
> Not every project is Hadoop.
Yes, that's absolutely true. The point I was trying to get across is
that I only have experience with Hadoop projects, and am therefore
biased in my experience. The community should consider other
opinions/insights, such as what you are raising.
>
> In Maven we do this all the time, both for Maven itself and the plugins. I recall doing it for Cocoon.
>
> http://archive.apache.org/dist/tomcat/tomcat-7/
> http://archive.apache.org/dist/httpd/
> http://archive.apache.org/dist/httpcomponents/httpclient/binary/
> http://archive.apache.org/dist/commons/lang/binaries/ (Notice that 3.0, which broke compatibility, had a beta)
> http://archive.apache.org/dist/jackrabbit/
>
> In fact, I would say it is more the norm to do this than not.
>
> Again, I'm used to dealing with Maven users. They will assume that if it doesn't have alpha or beta in the version then it isn't one.
Seems a reasonable approach. How do you decide what is alpha vs what
is beta vs a regular release? is there some special implication of
alpha vs beta?
Patrick
Re: Preparing for Flume 1.1.0
Posted by Mike Percy <mp...@cloudera.com>.
On Mar 13, 2012, at 5:59 PM, Ralph Goers wrote:
>
> On Mar 13, 2012, at 4:55 PM, Patrick Hunt wrote:
>
>> On Tue, Mar 13, 2012 at 4:31 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>> On Mar 13, 2012, at 4:08 PM, Eric Sammer wrote:
>>>
>>>> +1 on Arvind as 1.1.0 RM and on a 1.1.0 branch. +0 on labeling the release
>>>> beta. Kind of feel like it's something to list in the README (on advice
>>>> from phunt) and just release. Otherwise, it sounds like there will be a
>>>> 1.1.0 final (which the ASF doesn't do). The advice I got when we tackled
>>>> this with 1.0.0 was that the ASF produces releases, period. The quality can
>>>> be indicated in the README (unless I misunderstood).
>>>
>>> I'm not sure whose advice you got but other projects do versions like 1.2-beta all the time. IMO opinion labeling this 1.1-beta-incubating makes it clear to everyone what it is even without reading the README, including anyone typing the version in their pom - who almost never read those.
>>
>> A couple good items on the faq about this, see this for general details on what's a release:
>> http://www.apache.org/dev/release.html#what
>
> Releases are packages that have been approved for general public release, with varying degrees of caveat regarding their perceived quality or potential for change. Releases that are intended for everyday usage by non-developers are usually referred to as "stable" or "general availability (GA)" releases. Releases that are believed to be usable by testers and developers outside the project, but perhaps not yet stable in terms of features or functionality, are usually referred to as "beta" or "unstable". Releases that only represent a project milestone and are intended only for bleeding-edge developers working outside the project are called "alpha".
>
> While this doesn't mean you have to include the terms in the name but I read that as certainly implying it.
It is an important point that the name "1.1.0-beta" implies that we will have 1.1.0 RCs and then a 1.1.0 final. That's not what I thought I was voting for with a +1, I was thinking along the lines of what Apache Hadoop does by indicating the level of production use that occurred for the code line in the Release Notes. However, it's easy to see that the label Beta expresses a belief or opinion about the quality of the software.
In reality, we already know of people using Flume NG in production, and how are we to know whether it meets a potential user's production requirements or not? Whether it qualifies as Alpha or Beta or Final is subjective, and waiting around for everyone to think a release version is "final" sounds like an exercise in frustration to me. Let's just put a list of features and a list of known issues (Bug Jiras) in the release notes. Let's worry less about labels and more about making well-designed software and releasing regularly. If we find any very serious issues with a given release, we always have the option of doing a point release to fix it.
tl;dr: labels are too subjective, i say we leave it be
Mike
>
>>
>> Also this which goes into a bit more detail about types of releases:
>> http://www.apache.org/dev/release.html#release-typeso
>>
>> In neither of these cases is Apache proscribing how to "name" your
>> release however (although in the incubator you must indicate clearly
>> "incubating"). Just the process that must be followed to consider
>> something a release.
>>
>> My personal experience (granted it's with Hadoop related projects) is
>> that they typically do not include the quality level in the name
>> itself. Rather putting it in the readme, release notes, etc... But
>> that's up to you. Some projects at Apache certainly do this, but none
>> that i've been involved with. My personal preference is to have
>> release notes that cover any issues the user should be aware of,
>> rather than relying on "alpha/beta" labels in the name which might be
>> confusing.
>
> Not every project is Hadoop.
>
> In Maven we do this all the time, both for Maven itself and the plugins. I recall doing it for Cocoon.
>
> http://archive.apache.org/dist/tomcat/tomcat-7/
> http://archive.apache.org/dist/httpd/
> http://archive.apache.org/dist/httpcomponents/httpclient/binary/
> http://archive.apache.org/dist/commons/lang/binaries/ (Notice that 3.0, which broke compatibility, had a beta)
> http://archive.apache.org/dist/jackrabbit/
>
> In fact, I would say it is more the norm to do this than not.
>
> Again, I'm used to dealing with Maven users. They will assume that if it doesn't have alpha or beta in the version then it isn't one.
>
> Ralph
Re: Preparing for Flume 1.1.0
Posted by Ralph Goers <ra...@dslextreme.com>.
On Mar 13, 2012, at 4:55 PM, Patrick Hunt wrote:
> On Tue, Mar 13, 2012 at 4:31 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> On Mar 13, 2012, at 4:08 PM, Eric Sammer wrote:
>>
>>> +1 on Arvind as 1.1.0 RM and on a 1.1.0 branch. +0 on labeling the release
>>> beta. Kind of feel like it's something to list in the README (on advice
>>> from phunt) and just release. Otherwise, it sounds like there will be a
>>> 1.1.0 final (which the ASF doesn't do). The advice I got when we tackled
>>> this with 1.0.0 was that the ASF produces releases, period. The quality can
>>> be indicated in the README (unless I misunderstood).
>>
>> I'm not sure whose advice you got but other projects do versions like 1.2-beta all the time. IMO opinion labeling this 1.1-beta-incubating makes it clear to everyone what it is even without reading the README, including anyone typing the version in their pom - who almost never read those.
>
> A couple good items on the faq about this, see this for general
> details on what's a release:
> http://www.apache.org/dev/release.html#what
You didn't see this paragraph in the link above?
Releases are packages that have been approved for general public release, with varying degrees of caveat regarding their perceived quality or potential for change. Releases that are intended for everyday usage by non-developers are usually referred to as "stable" or "general availability (GA)" releases. Releases that are believed to be usable by testers and developers outside the project, but perhaps not yet stable in terms of features or functionality, are usually referred to as "beta" or "unstable". Releases that only represent a project milestone and are intended only for bleeding-edge developers working outside the project are called "alpha".
While this doesn't mean you have to include the terms in the name but I read that as certainly implying it.
>
> Also this which goes into a bit more detail about types of releases:
> http://www.apache.org/dev/release.html#release-typeso
>
> In neither of these cases is Apache proscribing how to "name" your
> release however (although in the incubator you must indicate clearly
> "incubating"). Just the process that must be followed to consider
> something a release.
>
> My personal experience (granted it's with Hadoop related projects) is
> that they typically do not include the quality level in the name
> itself. Rather putting it in the readme, release notes, etc... But
> that's up to you. Some projects at Apache certainly do this, but none
> that i've been involved with. My personal preference is to have
> release notes that cover any issues the user should be aware of,
> rather than relying on "alpha/beta" labels in the name which might be
> confusing.
Not every project is Hadoop.
In Maven we do this all the time, both for Maven itself and the plugins. I recall doing it for Cocoon.
http://archive.apache.org/dist/tomcat/tomcat-7/
http://archive.apache.org/dist/httpd/
http://archive.apache.org/dist/httpcomponents/httpclient/binary/
http://archive.apache.org/dist/commons/lang/binaries/ (Notice that 3.0, which broke compatibility, had a beta)
http://archive.apache.org/dist/jackrabbit/
In fact, I would say it is more the norm to do this than not.
Again, I'm used to dealing with Maven users. They will assume that if it doesn't have alpha or beta in the version then it isn't one.
Ralph
Re: Preparing for Flume 1.1.0
Posted by Patrick Hunt <ph...@apache.org>.
On Tue, Mar 13, 2012 at 4:31 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Mar 13, 2012, at 4:08 PM, Eric Sammer wrote:
>
>> +1 on Arvind as 1.1.0 RM and on a 1.1.0 branch. +0 on labeling the release
>> beta. Kind of feel like it's something to list in the README (on advice
>> from phunt) and just release. Otherwise, it sounds like there will be a
>> 1.1.0 final (which the ASF doesn't do). The advice I got when we tackled
>> this with 1.0.0 was that the ASF produces releases, period. The quality can
>> be indicated in the README (unless I misunderstood).
>
> I'm not sure whose advice you got but other projects do versions like 1.2-beta all the time. IMO opinion labeling this 1.1-beta-incubating makes it clear to everyone what it is even without reading the README, including anyone typing the version in their pom - who almost never read those.
A couple good items on the faq about this, see this for general
details on what's a release:
http://www.apache.org/dev/release.html#what
Also this which goes into a bit more detail about types of releases:
http://www.apache.org/dev/release.html#release-typeso
In neither of these cases is Apache proscribing how to "name" your
release however (although in the incubator you must indicate clearly
"incubating"). Just the process that must be followed to consider
something a release.
My personal experience (granted it's with Hadoop related projects) is
that they typically do not include the quality level in the name
itself. Rather putting it in the readme, release notes, etc... But
that's up to you. Some projects at Apache certainly do this, but none
that i've been involved with. My personal preference is to have
release notes that cover any issues the user should be aware of,
rather than relying on "alpha/beta" labels in the name which might be
confusing.
Patrick
Re: Preparing for Flume 1.1.0
Posted by Ralph Goers <ra...@dslextreme.com>.
On Mar 13, 2012, at 4:08 PM, Eric Sammer wrote:
> +1 on Arvind as 1.1.0 RM and on a 1.1.0 branch. +0 on labeling the release
> beta. Kind of feel like it's something to list in the README (on advice
> from phunt) and just release. Otherwise, it sounds like there will be a
> 1.1.0 final (which the ASF doesn't do). The advice I got when we tackled
> this with 1.0.0 was that the ASF produces releases, period. The quality can
> be indicated in the README (unless I misunderstood).
I'm not sure whose advice you got but other projects do versions like 1.2-beta all the time. IMO opinion labeling this 1.1-beta-incubating makes it clear to everyone what it is even without reading the README, including anyone typing the version in their pom - who almost never read those.
Ralph
>
> Thanks for volunteering, Arvind!
Agreed.
Ralph
Re: Preparing for Flume 1.1.0
Posted by Eric Sammer <es...@cloudera.com>.
+1 on Arvind as 1.1.0 RM and on a 1.1.0 branch. +0 on labeling the release
beta. Kind of feel like it's something to list in the README (on advice
from phunt) and just release. Otherwise, it sounds like there will be a
1.1.0 final (which the ASF doesn't do). The advice I got when we tackled
this with 1.0.0 was that the ASF produces releases, period. The quality can
be indicated in the README (unless I misunderstood).
Thanks for volunteering, Arvind!
On Tue, Mar 13, 2012 at 9:29 AM, Arvind Prabhakar <ar...@apache.org> wrote:
> On Tue, Mar 13, 2012 at 7:53 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > On Mar 12, 2012, at 10:59 PM, Juhani Connolly wrote:
> >>>>
> >>>
> >> While we have added some cool new features, and fixed some bugs, other
> new ones have appeared and some of the sub-tasks of the original flume-728
> task have been left by the wayside. We're talking about putting 1.1.0 out
> but there's no target for what 1.1.0 is meant to have? I hope we're not
> heading towards a development style of "release whatever we've done"
> without a plan.
> >
> > Software is never perfect. Apache philosophy has always been that it is
> better to release often than constantly be waiting for features or specific
> bug fixes - unless they are determined to be blockers. Users really like
> getting their hands on the software without having to build it.
> >
> > While I think roadmaps are great as a discussion point, the proof of
> what is needed is what the developers actually write and commit. It doesn't
> make sense to wait for something on the roadmap that no one really wants to
> implement or that users are OK with living without.
> >
> > That said, every attempt should be made to release software that does
> what it says it does and is reliable. That is why I asked the question
> about the version number. A release with just a number carries certain
> expectations that a release with "beta" in it doesn't have.
>
> I agree with Ralph's point here. We have had a 1.0.0 alpha release and
> what we release right now is going to be more of a beta than anything
> else. Primarily because of all the reasons Juhani pointed out - this
> release will leave room for improvement.
>
> +1 on officially labeling 1.1.0-incubating version as a "beta".
>
> We can continue to have the roadmap discussion and work out the plan
> for delivering the in-flight features in 1.2.0 which will should
> target to make a stable release.
>
> Thanks,
> Arvind Prabhakar
>
>
> >
> > Ralph
>
--
Eric Sammer
twitter: esammer
data: www.cloudera.com
Re: Preparing for Flume 1.1.0
Posted by Mike Percy <mp...@cloudera.com>.
On Mar 13, 2012, at 9:29 AM, Arvind Prabhakar wrote:
>
> On Tue, Mar 13, 2012 at 7:53 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> On Mar 12, 2012, at 10:59 PM, Juhani Connolly wrote:
>>>
>>> While we have added some cool new features, and fixed some bugs, other new ones have appeared and some of the sub-tasks of the original flume-728 task have been left by the wayside. We're talking about putting 1.1.0 out but there's no target for what 1.1.0 is meant to have? I hope we're not heading towards a development style of "release whatever we've done" without a plan.
>>
>> Software is never perfect. Apache philosophy has always been that it is better to release often than constantly be waiting for features or specific bug fixes - unless they are determined to be blockers. Users really like getting their hands on the software without having to build it.
>>
>> While I think roadmaps are great as a discussion point, the proof of what is needed is what the developers actually write and commit. It doesn't make sense to wait for something on the roadmap that no one really wants to implement or that users are OK with living without.
>>
>> That said, every attempt should be made to release software that does what it says it does and is reliable. That is why I asked the question about the version number. A release with just a number carries certain expectations that a release with "beta" in it doesn't have.
>
> I agree with Ralph's point here. We have had a 1.0.0 alpha release and
> what we release right now is going to be more of a beta than anything
> else. Primarily because of all the reasons Juhani pointed out - this
> release will leave room for improvement.
>
> +1 on officially labeling 1.1.0-incubating version as a "beta".
>
> We can continue to have the roadmap discussion and work out the plan
> for delivering the in-flight features in 1.2.0 which will should
> target to make a stable release.
+1 on a 1.1.0 beta. As long as we put in some critical build and stability fixes for bugs that crept in recently (FLUME-1027 & FLUME-1028), the state of Flume NG today is way better than it was at 1.0.0.
I agree with Juhani that we should pick up the discussion about where we are going. After reflecting a bit more on it, I'm not convinced that it would be effective to try and lock in what should go in the "next release" though, because releasing on a short schedule, say once a month, helps keep us honest about where we are and helps us eat the elephant one byte at a time (har har). Ralph you are right, few people want to build from source and deploy that to production. It's a lot of commitment to knowing what's going on with the state of the source tree.
Still, I think it is important for Flume for the developers to stay in sync with what each other are doing and try to move in the same direction. I think we should also collaborate on solving shared pain points of interest (e.g. FileChannel) if it's practical to work together on it.
Best,
Mike
Re: Preparing for Flume 1.1.0
Posted by Arvind Prabhakar <ar...@apache.org>.
On Tue, Mar 13, 2012 at 7:53 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Mar 12, 2012, at 10:59 PM, Juhani Connolly wrote:
>>>>
>>>
>> While we have added some cool new features, and fixed some bugs, other new ones have appeared and some of the sub-tasks of the original flume-728 task have been left by the wayside. We're talking about putting 1.1.0 out but there's no target for what 1.1.0 is meant to have? I hope we're not heading towards a development style of "release whatever we've done" without a plan.
>
> Software is never perfect. Apache philosophy has always been that it is better to release often than constantly be waiting for features or specific bug fixes - unless they are determined to be blockers. Users really like getting their hands on the software without having to build it.
>
> While I think roadmaps are great as a discussion point, the proof of what is needed is what the developers actually write and commit. It doesn't make sense to wait for something on the roadmap that no one really wants to implement or that users are OK with living without.
>
> That said, every attempt should be made to release software that does what it says it does and is reliable. That is why I asked the question about the version number. A release with just a number carries certain expectations that a release with "beta" in it doesn't have.
I agree with Ralph's point here. We have had a 1.0.0 alpha release and
what we release right now is going to be more of a beta than anything
else. Primarily because of all the reasons Juhani pointed out - this
release will leave room for improvement.
+1 on officially labeling 1.1.0-incubating version as a "beta".
We can continue to have the roadmap discussion and work out the plan
for delivering the in-flight features in 1.2.0 which will should
target to make a stable release.
Thanks,
Arvind Prabhakar
>
> Ralph
Re: Preparing for Flume 1.1.0
Posted by Ralph Goers <ra...@dslextreme.com>.
On Mar 12, 2012, at 10:59 PM, Juhani Connolly wrote:
>>>
>>
> While we have added some cool new features, and fixed some bugs, other new ones have appeared and some of the sub-tasks of the original flume-728 task have been left by the wayside. We're talking about putting 1.1.0 out but there's no target for what 1.1.0 is meant to have? I hope we're not heading towards a development style of "release whatever we've done" without a plan.
Software is never perfect. Apache philosophy has always been that it is better to release often than constantly be waiting for features or specific bug fixes - unless they are determined to be blockers. Users really like getting their hands on the software without having to build it.
While I think roadmaps are great as a discussion point, the proof of what is needed is what the developers actually write and commit. It doesn't make sense to wait for something on the roadmap that no one really wants to implement or that users are OK with living without.
That said, every attempt should be made to release software that does what it says it does and is reliable. That is why I asked the question about the version number. A release with just a number carries certain expectations that a release with "beta" in it doesn't have.
Ralph
Re: Preparing for Flume 1.1.0
Posted by Juhani Connolly <ju...@cyberagent.co.jp>.
On 03/13/2012 02:17 PM, Ralph Goers wrote:
> The only question I have is whether the community considers this release "stable" or "ready for production" use. If not, I would think using "beta" in the release version would be helpful. I know that wasn't done for 1.0.0 but I kind of wish it had.
>
> Ralph
I think in its current state if anyone tried to use this in production
they would have some pretty nasty surprises. E.g. reconfiguring a
running agent is still very broken, there are still some thread safety
issues, and not all components are consistent in their behaviors.
> On Mar 12, 2012, at 9:59 PM, Arvind Prabhakar wrote:
>
>> Hi,
>>
>> Since the release of version 1.0.0-incubating of Flume, we have made
>> significant progress in terms of development. Also of significance is
>> the fact that we have promoted the active development branch to trunk.
>> We are now technically ready to graduate as a top-level project (TLP).
>> To ensure that we do not get bogged down by various concerns that
>> people have expressed in the graduation of other projects, it is
>> prudent on our part to make a release from the trunk.
>>
>> For this reason, I am proposing myself to be the release manager for
>> the upcoming release - version 1.1.0-incubating. The goal of this
>> release will be to create a distribution from the trunk where all
>> sources are in the expected org.apache.* namespace. It will also have
>> significantly more features and bug fixes than the previous release.
I tried earlier to get some discussion kicked off on a roadmap for 1.1.0
to which Mike Percy provided some useful input. What is going in it? Are
we just going to freeze it at the current feature set and fix bugs? Is
Hari's reworking of the configuration going in? Are we going to try and
get a FileChannel implementation in(I personally think this is a pretty
big deal but it seems to have fallen by the wayside). I suppose that a
centralized configuration is not planned for this release then?
>> In order to bootstrap the process, I will go ahead and create the
>> release branch right away. If during the discussion on this thread we
>> feel that the release must contain certain patches not part of this
>> branch, I will be happy to port them over to the release branch if
>> they are committed to the trunk.
>>
>> Thanks,
>> Arvind Prabhakar
>
While we have added some cool new features, and fixed some bugs, other
new ones have appeared and some of the sub-tasks of the original
flume-728 task have been left by the wayside. We're talking about
putting 1.1.0 out but there's no target for what 1.1.0 is meant to have?
I hope we're not heading towards a development style of "release
whatever we've done" without a plan.
Re: Preparing for Flume 1.1.0
Posted by Ralph Goers <ra...@dslextreme.com>.
The only question I have is whether the community considers this release "stable" or "ready for production" use. If not, I would think using "beta" in the release version would be helpful. I know that wasn't done for 1.0.0 but I kind of wish it had.
Ralph
On Mar 12, 2012, at 9:59 PM, Arvind Prabhakar wrote:
> Hi,
>
> Since the release of version 1.0.0-incubating of Flume, we have made
> significant progress in terms of development. Also of significance is
> the fact that we have promoted the active development branch to trunk.
> We are now technically ready to graduate as a top-level project (TLP).
> To ensure that we do not get bogged down by various concerns that
> people have expressed in the graduation of other projects, it is
> prudent on our part to make a release from the trunk.
>
> For this reason, I am proposing myself to be the release manager for
> the upcoming release - version 1.1.0-incubating. The goal of this
> release will be to create a distribution from the trunk where all
> sources are in the expected org.apache.* namespace. It will also have
> significantly more features and bug fixes than the previous release.
>
> In order to bootstrap the process, I will go ahead and create the
> release branch right away. If during the discussion on this thread we
> feel that the release must contain certain patches not part of this
> branch, I will be happy to port them over to the release branch if
> they are committed to the trunk.
>
> Thanks,
> Arvind Prabhakar