+1(non-binding) to me for iterative release for maintenance release. It's useful for end users to get stable version as soon as it fixed.
> For 0.9, I think it will be useful to adopt a model where features are added in point releases (the third digit changes). Also, make release more often - on a schedule - every 1.5-2 months, when a feature reaches a logical conclusion, and as and when required. About 0.9, my concern is that the point releases with the third digit changes can confuse end-users. IMHO, 0.9-alpha-1, 0.9-alpha-2 seems be more straight forward to me. Thanks, - Tsuyoshi On Thu, Jun 23, 2016 at 6:30 PM, Bikas Saha <[email protected]> wrote: > Its good to target big features to major release lines. At the same time > have a regular cadence of dot releases helps get bits into user hands to try > out. This way we know a release is coming every 3-6 months and different > parts of the major feature could latch onto different releases. E.g. get > alpha out for trial in 1 release and then GA out in the next, hopefully > benefiting from trials/bug-reports from the alpha. > > Bikas > > -----Original Message----- > From: Hitesh Shah [mailto:[email protected]] > Sent: Thursday, June 23, 2016 9:12 AM > To: [email protected] > Subject: Re: [DISCUSS] Release going forward > > +1 on a 0.8.4 release soon to keep a regular cadence on maint lines. > > A couple of points on the points on features/releases from master/0.9: I > think that we might be better off targeting a defined set of features for a > given release. For example, the new edges being introduced would make a good > set of features to introduce in 0.9. A completely different set could end up > being targeted to 0.10. It is likely that these new edges will require some > changes in the core to support them fully. In that regard, we could probably > do a release of master initially if there are no other major features being > targeted in the near future but we may need to branch off for 0.9 to allow > the new edges to stabilize and allow other communities like Hive to rely on > a more stable 0.9 maint line as compared to master-based releases which may > be stable but would make folks a bit nervous if we are also adding other > features :) > > But yes, agreed that we do need to figure out a plan to reduce the overall > no. of branches to keep active and support them whilst adding these new > features. Feature branches will likely help here and we may need to consider > a concept of branch committers to try and allow non-committers to work with > committers to progress faster on these branches. > > thanks > -- Hitesh > > >> On Jun 21, 2016, at 6:03 PM, Siddharth Seth <[email protected]> wrote: >> >> Hi Folks, >> I'd like to start a discussion around how we maintain various branches >> (features vs bug-fixes), releases from various branches - stability, >> release schedules etc. >> >> This is how I look at the current active branches. >> branch-0.7 - Mainly gets bug-fixes. >> branch-0.8 - Targets improvements to external service integration >> (TEZ-2003), bug fixes master (0.9) - Gets everything for now. >> >> Feature development is not at the same pace that it has been in the past. >> The main features being worked on actively at the moment are >> TEZ-3209(Handling skewed data without ordering requirements) and >> TEZ-2104 (CrossProductEdge), and UI enhancements. >> >> Downstream projects typically need a released version to integrate >> with (projects don't want to depend upon a SNAPSHOT in their main > branches). >> >> For 0.9, I think it will be useful to adopt a model where features are >> added in point releases (the third digit changes). Also, make release >> more often - on a schedule - every 1.5-2 months, when a feature >> reaches a logical conclusion, and as and when required. >> The main features for these releases would be TEZ-2104, TEZ-3209, UI, >> and additional TEZ-2003 changes. Addition of more features can be >> discussed as required - i.e. whether to continue landing them on 0.9 >> or create the next 'major' version. Bug fixes, would go into all active > branches. >> >> One thing we'll have to be careful about is to not destabilize the >> master branch. Half done features are OK - but anything which could >> destabilize the branch and needs multiple jiras to stabilize would be >> developed in a branch (so that release can continue off of master). >> >> The release notes which go out with a release can call out the new >> features in various 0.9 releases, and there level of stability. >> >> We can create a release from 0.9 once at least some set of features >> have gone in. Meanwhile, external services continues to evolve via 0.8 >> releases (Will create a new release later this week). >> >> >> Thoughts? >> >> Thanks, >> Sid > > >
