Guys, thank you for sharing!

I also have similar experience of user questions about upcoming releases
and I really love the idea of setting user expectations for Zeppelin to be
released as often as possible, but at least every 2-4 months. As you know,
there tend to be a lots of great contributions\improvements worth
publishing.

Having issues for every coming release is a great idea and I think we are
already following the pattern with [1] [2] [3] for initial release as well
as 0.5.5 and 0.5.6 with rotation of RM responsibilities among contributors
members.

Adopting semantic versioning is another great idea, it is not
applied\discussed yet, so it is definitely worth the discussion but may be
we could take it to the separate thread, apart from the subject of this one
and go on from there.

  1. https://issues.apache.org/jira/browse/ZEPPELIN-51

  2. https://issues.apache.org/jira/browse/ZEPPELIN-311

  3. https://issues.apache.org/jira/browse/ZEPPELIN-566

--

Alex
On Tue, Mar 8, 2016, 03:53 moon soo Lee <m...@apache.org> wrote:

> Jeff,
>
> Thank you for the link about Semantic Versioning.
> I don't think Zeppelin project were following versioning scheme described
> at http://semver.org/, right now.
> But it's good idea to define one for the project.
>
> Amos,
> People asking schedule of next version is coming out because of they don't
> know the schedule. And nobody can answer it because of nobody knows. Date
> driven approach can give an answer.
>
> And please be aware of project is being driven by feature for now. There're
> no such things that project is behind schedule while project don't set any
> date for the roadmap.
>
> 0.5.5 and 0.5.6 are released because of there're bug fixes and improvements
> that we think worth to be released. And yes, that helps graduation and
> that's how project grows and graduate.
>
> Thanks,
> moon
>
> On Mon, Mar 7, 2016 at 9:47 AM Amos B. Elberg <amos.elb...@gmail.com>
> wrote:
>
> > 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
> > >>
> >
>

Reply via email to