My comments are below.
On Thu, Mar 20, 2014 at 3:05 PM, Srikanth Sundarrajan <[email protected]>wrote: > I guess the larger question is do we want to have a multiple release line > at different levels of maturity, if so what are the best practices here and > how can we adopt them. I'm NOT talking about releases at different levels of maturity. I think this is a complete disaster for users as it can be quite confusing. Again, to reiterate what I was saying: "We need to accommodate features that are not stable and well tested as part of a regular release, mark 'em as such so users are aware of whats stable and whats not." Am I clear? > Perhaps we can study some of the projects and figure what works best for > us. > There is no need IMO. > > There are bug fixes and new features being added simultaneously and there > ought to be frequent releases to stable version with bug fixes to help > users who use the software in production system. Similarly there may be > users who are waiting on new features, but aren't concerned about the > stability of the software and are largely in test deployments. > This is exactly my point. We need to establish a regular release cadence so users can expect a release on a set cycle with clarity in release notes saying which features are stable, new and experimental, alpha, etc. A feature will NOT get stable in a single release but will take at least 2 cycles. This is how Flume works. Makes sense? > > My initial thoughts: We can branch out stable line and make stable > releases from this branch and release alpha-versions from trunk. But having > more than 2 release lines is going to be quite burdensome. This is bad and confusing. Lets not do this. > At some point there has got to be enough work done before the old stable > line is closed and trunk is promoted as the new stable line. Assuming 0.5 > is released as alpha, before we add more features there has to be an effort > to move 0.5 to beta quality (let us call this 0.6) and then branch out post > 0.6 to have stable releases out of this (0.6.1). So between 0.5 and 0.6.1 > new feature releases are a burden. > > Since we released 0.4, we haven't done much to mature the features added > there and hence the suggestion to defer 0.5. I humbly disagree. There has been innumerous bugs fixed since then and some are critical. BTW, the larger question is also to establish a release cadence, monthly, once in 2 months, quarterly, etc. We can have an exception but we now can communicate to users to expect a release regularly. > If there is push from the users needing new features added since 0.4 > packaged in a release, we can proceed with 0.5. But I feel that we ought to > mature features that have already been added and have these rolling out in > frequent releases to allow users to use these features in production > deployments. > Hive was added in 0.4. Until we get to 0.6, Hive will not be mature and must not be used in Production. Lets allow atleast 2 release cycles before marking it as stable and we can measure it based on Merlin coverage as well once it gets folded into apache. > > Regards > Srikanth Sundarrajan > > > Date: Thu, 20 Mar 2014 09:57:31 -0700 > > Subject: Re: [DISCUSS] falcon 0.5 release > > From: [email protected] > > To: [email protected] > > > > HCat was not tested with dated sub partitions. Having a fix for these is > a > > good idea but there is a dependency on Oozie for this and not sure how > this > > plays out. The retention already has a patch and will review/commit it > this > > week. > > > > What else is open wrt stability. There will be bugs and holding off a > > release calling out experimental features unstable is not a good thing. I > > also wanted to start a discuss thread to explore ideas to see how we can > > make adding new features a breeze and mark 'em as experimental. These > > features should take couple of release cycles to bake in and will be > marked > > Beta/GA to be used in production. > > > > In that light, you could release a 0.4.1 stable version but I can go > ahead > > and make a 0.5 - experimental release with new features for users to play > > with. Lineage is not fully baked. Security for a large part has been > tested > > but can be marked beta. > > > > Thoughts? > > > > > > > > > > On Wed, Mar 19, 2014 at 2:30 AM, Srikanth Sundarrajan > > <[email protected]>wrote: > > > >> Was seriously contemplating a 0.4.1 stability release over the next 3-4 > >> weeks as 0.4 has many bugs particularly with respect to the hcat > >> replication and retention feature involving multiple partitions. Does it > >> make sense to hold off on 0.5 till End of Apr ? > >> RegardsSrikanth Sundarrajan > >> > >>> Date: Wed, 19 Mar 2014 07:00:53 +0100 > >>> From: [email protected] > >>> To: [email protected] > >>> Subject: Re: [DISCUSS] falcon 0.5 release > >>> > >>> Hi Venkatesh, > >>> > >>> on my side, I should be able to submit new patches proposal soon (next > >>> week max). > >>> > >>> So, no problem for EOM release for me. > >>> > >>> Thanks, > >>> Regards > >>> JB > >>> > >>> On 03/19/2014 06:58 AM, Seetharam Venkatesh wrote: > >>>> Hey folks, > >>>> > >>>> We have made significant progress in falcon with security and lineage > >> apart > >>>> from the many bug fixes. Should we have a release by EOM? > >>>> > >>> > >>> -- > >>> Jean-Baptiste Onofré > >>> [email protected] > >>> http://blog.nanthrax.net > >>> Talend - http://www.talend.com > >> > >> > > > > > > > > -- > > Regards, > > Venkatesh > > > > "Perfection (in design) is achieved not when there is nothing more to > add, > > but rather when there is nothing more to take away." > > - Antoine de Saint-Exupéry > -- Regards, Venkatesh "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away." - Antoine de Saint-Exupéry
