I agree with what Vinod mentioned: we need to revisit all incompatible
changes and revert unnecessary ones. Even if we don't have any
compatibility guarantees between 2.x and 3.x. But make user to be less
frustrated while trying 3.x is always a better option to me.

To achieve this we need to run jdiff for trunk and look at results. I would
suggest to do this before 3.0.0-alpha1 release.

In addition, for people who will try this 3-alpha1 release artifacts, a
guide about migration from 2.x to 3.x will be very helpful, and it can also
help for people to better understand what have changed (Just like
http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html
)

Thoughts?

Thanks,
Wangda


On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bus...@cloudera.com> wrote:

> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
> <vino...@apache.org> wrote:
> >> I really, really want a 3.0.0-alpha1 ASAP, since it's basically
> impossible for downstreams to test incompat changes and new features
> without a release artifact. I've been doing test builds, and
> branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version
> issue.
> >
> > Not arguing against the need for an alpha release, the question is if it
> can wait till after 2.8 gets done.
> >
> > Orthogonally, do we have a report of the incompatible changes? Like the
> one I generated for some of the branch-2 releases using late jdiff work
> from Li Lu etc. We should do this and fix any inadvertant
> incompatibilities. Without seeing this list of incompatibilities, why even
> make an alpha release and force downstream components to discover issues
> what can be identified through running reports.
> >
>
> I can come up with this, atleast for Source / Binary API compatibility,
> provided folks don't mind if I use the Java API Compliance Checker[1]
> instead of jdiff.
>
> I'm already familiar with quickly using it, esp with Audience
> Annotations from my work in HBase.
>
> Do you want this check from some particular branch-2 release? It
> matters since the releases along branch-2 have themselves had some
> noise[2].
>
> [1]: https://github.com/lvc/japi-compliance-checker
> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/
>
> --
> busbey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: common-dev-h...@hadoop.apache.org
>
>

Reply via email to