Moon - people asking when the next version is coming out, I don't think that's a request to shift from a feature-based to a date-based release people policy. It's just asking when the next release is.
The logic that even without date-based releases there will be releases every 2-4 months because that's how we've been doing it, doesn't make sense. 0.5.5 and 0.5.6 were interim releases, because the project was behind schedule but some folks still wanted to do a "release," apparently because of graduation. For two releases we've said "hey we're behind schedule but it's been so long since a release let's just do one now anyway." What would be the benefit in institutionalizing that? > On Mar 7, 2016, at 12:24 PM, moon soo Lee <m...@apache.org> wrote: > > Thanks for the feedbacks. > > Jeff, > If we define version number X.Y.Z as MAJOR, MINOR, PATCH, then regular > MINOR / PATCH release make sense to me. > > Amos, > One of the most frequent questions i got from users, in the conference, > meetups, personal email are when the next version will be released. And I > think date driven policy is one way to answer the question. > > Cos, > Thanks for the helpful hint! > > > Here is interval of Zeppelin previous releases. > > 0.5.6 - 2 Months since 0.5.5 > 0.5.5 - 4 Months since 0.5.0 > 0.5.0 - First release since incubation > > Considering previous release interval and code contributions to the > project, and I can guess release will be made every 2~4 months anyway, even > without adopting date driven release policy. > > Therefore, if we setup an release interval of date driven release between > 2-4 months, then it'll not bring much additional overhead to the project > but help setting up expectation to the next release. > > > Any thoughts? > > Thanks, > moon > > >> On Fri, Mar 4, 2016 at 12:56 PM Konstantin Boudnik <c...@apache.org> wrote: >> >> I don't want to sway this discussion one way or another, so I will just >> make a >> data point (or perhaps a helpful hint ;) >> >> In Bigtop (and in some other projects I've partaken/observed) the content >> of >> the release would be discussed either on the dev@ list or in a special >> JIRA. >> One such example would be an ongoing BIGTOP-2282 or already completed >> BIGTOP-2078. >> >> This way an RM can always gauge the level of interest for different >> features >> and make an educated guess on when to cut an RC. >> >> Cos >> >>> On Fri, Mar 04, 2016 at 03:47PM, moon soo Lee wrote: >>> Hi folks, >>> >>> Zeppelin project used made releases driven by feature. >>> I'm getting constant feedback from users about moving to date-driven >>> release policy from current feature-driven. (such as major release every >> 3 >>> months) >>> >>> They have pros and cons. The question is, which policy is better for >> users >>> and developers of this project? >>> >>> One good thing about date driven approach i think is, Zeppelin usually >> gets >>> a lot of contributions not in the release scope. Date driven policy can >>> give user expectation of availability of those contributions. >>> >>> What do you think? Can you share your experiences and opinions? >>> >>> Thanks, >>> moon >>
