Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> Logistics for releasing 2.4

Copy link to this message
Re: Logistics for releasing 2.4
Hi Vinod,

If the main point of contention is the alpha/beta/stable labeling for
features, we can just not include anything but stable features in the
proposed 2.4. This means HDFS-2832 and HDFS-4949 (along with the plethora
of other improvements that have gone in since 2.2). AFAIK the previous plan
(per Roadmap on the wiki) was a 2.4 in Jan, and since Arun said the 2.3 rc
is almost ready, I think we can squeeze out a 2.4 immediately after.
Another option (not to step on anyone's toes) is to scratch the current 2.3
branch and make HDFS-2832+HDFS-4949 the new 2.3, since the current 2.3 has
sort of lost its way as a bugfix-only release, and has diverged quite a bit
from branch-2.

As to a more frequent release cadence, it seems like so far there's a lot
of support. I think downstreams would actually appreciate more frequent
releases. HBase at least only builds against release artifacts, so they end
up scrambling whenever we drop a new release. Releasing more often will
force us to streamline the integration testing process, which in turn means
we'll do it more and reveal incompatibilities sooner. Since I'm
volunteering to RM some of these, that part of the burden goes away as well.

Overall, I'm pushing for this because I'd really like to see high-quality,
compatible releases come out of the 2.x line, and this seems like one of
the best way to make that happen. I plan to cut branch-2.4 tomorrow and
start firming things up.


On Wed, Jan 22, 2014 at 12:48 PM, Vinod Kumar Vavilapalli <

> I think YARN-149 will be ready if we do a 2.4 release sometime next month.
> The same goes for YARN-321 also. The merge-to-trunk vote is happening now
> and it should be in a good shape soon *if *we stick to the early plan
> that is laid out in the roadmap. Overall, a bunch of us in the YARN side
> have been working on features like YARN-149 and YARN-321 assuming a target
> release of 2.4. Release numbers don't make a big deal, but we need to be
> sure about the perceived and publicized stability of these features. For
> e.g., what is the story of compatibility if we ship alpha/beta YARN-149 in
> 2.4 by this month-end? I'd like us all to agree labeling features as
> alpha/beta/stable formally before making an offhanded decision. Will start
> a separate thread for this.
> Also, we are yet to release a 2.3? The RC is supposedly a WIP and we'll
> take a week for its release. Which will already be end of the month. Shall
> we wait till that goes out? Cutting a branch for 2.4 next week or end of
> this month seems reasonable and inline with the previous plans. What are
> the timelines for the 2.4 release accordingly if 2.5 were to be started
> middle of next month.
> Overall, may be I am missing some threads, but, have we discussed and
> already decided on this new way of monthly release-plans? Even if we did, I
> don't recall us saying it will start with 2.4 and don't see an urgency for
> it to be. Let's start that new process with 2.5 if there is an apparent
> agreement. We will also need to figure out more things before we take this
> plunge. Some them include:
>  - What happens to WIP features? Shall we start calling them
> alpha/beta/stable?
>  - How do we communicate the non-readiness of some WIP features?
>  - What about the compatibility story of WIP features across these monthly
> releases?
>  - A monthly release with a release-vote that takes a week? That seems
> like a terrible overhead.
>  - What about downstream projects? BigTop is in with these monthly cycles?
> Thanks,
> +vinod
> On Jan 22, 2014, at 12:04 PM, Andrew Wang <[EMAIL PROTECTED]>
> wrote:
> Thanks for the comments everyone.
> Vinod, if you think YARN-149 isn't ready yet, we can leave it out.
> Alternatively, we could release note it as "beta" with said known issues,
> and let people kick the tires. It looks like a bunch of the core
> functionality is already in place.
> Unless anyone else objects, I plan to cut a 2.4 branch later this week.