Hi Juhani, On Mon, Mar 19, 2012 at 2:45 AM, Juhani Connolly <juhani_conno...@cyberagent.co.jp> wrote: > On 03/19/2012 06:01 PM, Arvind Prabhakar wrote: >> >> [X] -1 No - Flume should adopt some other policy >> >> For two reasons: >> >> 1. The Apache Commons versioning policy is an elaborate policy that >> categorizes interface type, based on which it defines the change types >> along with the development states that the project can be in. This is >> very rigid and process heavy for Flume in it's current state. >> >> 2. Labeling a release as beta in the version number implies that there >> are no plans for feature addition and all work will go towards >> stabilizing the artifacts. We cannot afford such constraint so early >> in the life of the project. If we have a multitude of contributors who >> are willing to dedicate all their work on a beta branch to stabilize >> it, then it makes sense to follow such policy. > > This reason makes sense in the mental context you have for the release but > highlights to me a communication failure in that I think others may have had > a different image. > > I would just like to question what exactly our objective in providing this > release is so that we can decide what state we want it out in and what label > is most appropriate for such a state. I think there is some confusion > regarding this.
The primary objective of this release, as is the case with any other release, is to provide access to various features and bug fixes that have gone into the system since the last release. The secondary objective of this release is to provide some binaries in the hands of our users who may not want to compile the system from the release sources. A distant third objective for this release is to prepare ourselves for graduation. > > What you are saying makes it sounds like the release is a glorified snapshot > that we've decided to label as a release. Perhaps there is still some > communication lacking. Before we can decide on a name for the release, I > think we need to decide on what is going to go in, because I don't think > there is a concensus on that. We can't name the baby if we don't know if > it's a boy or a girl. The model that I have followed so far, and have seen being followed in other projects is this: Every release on the same major version line is an incremental improvement over the previous release. It will likely have more features and bug fixes, along with possibly some regression which will be prioritized for being resolved in the follow-up releases. As long as the major versions do not change, compatibility is assumed although migration may be required between versions. The advantage of using this model is that all major version lines automatically move towards stable releases over a period of time driven by user issues and field feedback. This is way better metric than having developers decide on what the quality of the release really is, when there is no formal way to measure or enforce it without incurring the cost of inhibiting community driven development. Thanks, Arvind Prabhakar
