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. Perhaps we can study some of the projects and figure what works best for us.
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. 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. 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. 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. 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
