falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajay Yadav <ajayn...@gmail.com>
Subject Re: [DISCUSS] : Apache Falcon minor release schedule
Date Thu, 07 Apr 2016 10:00:55 GMT
After observing both formats across several releases I have also become a
strong supporter of Approach #2.
Releasing early has improved the project in many ways. Earlier we were
making releases after several months and we didn't invest time in improving
the release and testing process. Early release forced us to invest time in
these tasks and we have seen continuously better release candidates across
last several releases.

As for incomplete features going in, as Srikanth said this is a non-issue
as long as we don't advertise those features being available and in
practice it has been working out very well for us. Unlike approach 1 it
encourages us to follow the Apache way by putting in small changes in
community instead of dumping large features at the end and pushing them in
to make in a release. It also helps us to get quick feedback on changes
instead of making assumptions and making large changes based on those
assumptions.

Approach 1 also blocks certain changes if they are not supposed to be in
the release or will affect a feature marked for the release. Though
infrequent, in practice this hampers the community contribution in some
cases.



On Thu, Apr 7, 2016 at 8:51 AM, Srikanth Sundarrajan <sriksun@hotmail.com>
wrote:

> I am personally a strong advocate of Approach #2. I believe "release early
> release often" is the right model for open source projects. There are
> numerous examples of where this is successfully adopted and community
> benefiting from. If the overheads of a releases are reduced and managed
> well, this ought to be a non-issue. While there are projects that do
> releases one or even twice in a month, we can certainly do with a 6-8 week
> release cycle.
>
> >> The disadvantage is that there could be incomplete features going into
> Falcon, leading to customers trying out and struggling with these
> features.
>
> This is only an issue if the feature is prematurely advertised as being
> available, as long as new features don't break existing functionality.
> Luckily we have a reasonable test suite.
>
> Regards
> Srikanth Sundarrajan
>
>
> > Subject: [DISCUSS] : Apache Falcon minor release schedule
> > From: bvellanki@hortonworks.com
> > To: dev@falcon.apache.org
> > Date: Wed, 6 Apr 2016 18:39:11 +0000
> >
> > Hello Team,
> >
> > We had a discussion on the scope and schedule of Apache Falcon minor
> releases during the Falcon bi-weekly meeting. There were two approaches
> suggested. I request you to provide your feedback/opinion on what is the
> preferred way.
> >
> > Approach 1 : Minor release should be feature based.
> > In this approach, the release manager will coordinate with the Falcon
> community and come up with an short wish-list of features that should go
> into next release. The list should be achievable in the timelines proposed.
> Once the list is decided upon, the release will happen only after the
> features are complete (including full testing).  The advantage is that
> minor releases will be feature complete and stable. Community will spend
> less time on debugging incomplete features.  The disadvantage is that the
> release timeline becomes unpredictable due to unforeseen feature delays.
> >
> > Approach 2 : Minor release should be time bound.
> > In this approach, minor releases will be done on a regular time interval
> proposed to be once a month. Every month, if we have a single complete
> feature committed to Falcon, a new branch will be cut and a minor release
> will be made. Incomplete features can go into the release, but they will
> not be advertised. The advantage is that falcon will have faster and
> predictable release cycles. The disadvantage is that there could be
> incomplete features going into Falcon, leading to customers trying out and
> struggling with these features.
> >
> > Thank you
> > Balu Vellanki
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message