I am not too sure if I understand this well enough. "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."
If new features are not well tested, but they are touching areas of code that are considered stable, how do we ensure there are no regressions on those existing features without at least testing the newly added code paths introduced by the new features. Am I missing something that is seemingly obvious? Regards Srikanth Sundarrajan ---------------------------------------- > Date: Fri, 21 Mar 2014 14:07:24 -0700 > Subject: Re: [DISCUSS] falcon 0.5 release > From: [email protected] > To: [email protected] > > 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
