I’m not sure what would be confusing about the numbering. Assumably the next feature bearing release will be 2.2. The next one after that 2.3. We should make a rule that patches in version x don’t go away in x+1. With that I don’t see any confusion.
I agree we shouldn’t turn master into a dumping ground that we never release off of (the way Hadoop has). I assume we will still make releases off of master in the future. I believe what Owen is proposing is a shorter path to a stable release, rather than waiting until master is completely stable. That makes sense to me. Alan. > On Nov 29, 2016, at 14:00, Sergey Shelukhin <ser...@hortonworks.com> wrote: > > We need to figure out the versioning strategy for this that is not > hopelessly confusing. > Also, having too many fixes in master as described is a different problem, > of not releasing off master often enough. > What is to be done with master in this model? > > On 16/11/29, 12:37, "Sergio Pena" <sergio.p...@cloudera.com> wrote: > >> Good, thanks Owen for volunteering. >> >> I see we have too many bugfixes, features, and improvements on the master >> branch. >> >> A few questions: >> >> - How or what would be the process for cherry picking those fixes? How >> will >> you detect which ones are stable and which not? >> >> - What if others contributors want some patches to be added to the next >> release? How can we prove they're stable enough to be included? >> >> - How can the community help on making this new branch stable? Should we >> help on triaging, cherry-picking, testing, others ideas? >> >> I really agree we should be careful on doing the next feature release >> stable. >> Having hundred of new bugfixes and improvements on a branch makes >> difficult >> to validate its quality. >> >> - Sergio >> >> >> On Tue, Nov 29, 2016 at 12:31 PM, Owen O'Malley <omal...@apache.org> >> wrote: >> >>> Hi all, >>> I'd like to volunteer as a Release Manager for making a stable >>> feature >>> release from branch 2. However, rather than starting with master, I'll >>> use >>> the 2.1 release and cherry pick fixes and features with a focus on a >>> stable >>> release and picking features that have been tested at scale. Testing a >>> Hive >>> release at scale is hard, time consuming, and resource intensive, but I >>> think that having a stable release with some of the great features that >>> we've put into Hive 2 will help drive adoption of the new branch. >>> >>> Thanks, >>> Owen >>> >
