hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 俊平堵 <junping...@apache.org>
Subject Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]
Date Wed, 27 Jul 2016 16:10:03 GMT
Thanks Vinod for bringing up this topic for discussion. I share the same
concern here from my previous experience and I doubt some simple rules
proposed below could make life easier.

> The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix
versions.
> Allen's historical perspective is that we've based each minor or major
> release off of the previous minor release. So, 2.8.0 would be based off of
> 2.7.0. Assuming 3.0.0-alpha1 happens before 2.8.0, 3.0.0-alpha1 would also
> be based off of 2.7.0. This also makes sense from a user POV; someone on a
> 2.6.x going to 3.0.0-alpha1 can look at the 2.7.0 and 3.0.0-alpha1 notes
to
> see what's changed.
This is not correct - not reflecting the past and not helpful for the
future. There is no benefit to claim 3.0.0-alpha1 is based on 2.7.0 over
2.7.3 (in case 2.8.0 is not there).
In the past, for example, when we cut off 2.7, we already have 2.6.0 and
2.6.1 get released, so 2.7.0 take all commits from 2.6.1 (not 2.6.0). In
future, assume when we start the release effor of 3.1.0 and we have 3.0.1,
3.0.2, etc., 3.0.x should be more stable than 3.0.0-alpha, so there is
unnecessary to do everything from scratch (3.0.0-alpha). So the rule here
should be: a new major or minor release should come from a release:
1. tag with stable
2. released latest
3. with maximum version number
If condition 2 and 3 get conflicts, we should give priority to 3. For
example, when 3.0.0-alpha1 is about to release, assume we have 2.8.0, 2.7.4
and 2.7.4 get released after 2.8.0, then we should claim 3.0.0-alpha is
based on 2.8.0 instead of 2.7.4.


> As an example, if a JIRA was committed to branch-2.6, branch-2.7,
branch-2,
> branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
2.7.3,
> 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> rule 1, and the last two fix versions come from rule 2.
I don't think setting version tags to be more than 3 is a good practice.
The example above means we need to backport this patch to 5 branches which
make our committers' life really tough - it requires more effort of
committing a patch and also increases the risky of bugs that caused by
backport. Given realistic community review bandwidth (please check another
thread from Chris D.), I strongly suggest we keep active release train to
be less than 3, so we can have 2 stable release or 1 stable release + 1
alpha release in releasing.

BTW, I never see we have a clear definition for alpha release. It is
previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
but sometimes means unstable in production quality (2.7.0). I think we
should clearly define it with major consensus so user won't
misunderstanding the risky here.
Also, if we treat our 3.0.0-alpha release work seriously, we should also
think about trunk's version number issue (bump up to 4.0.0-alpha?) or there
could be no room for 3.0 incompatible feature/bits soon.

Just 2 cents.

Thanks,

Junping

2016-07-27 15:34 GMT+01:00 Karthik Kambatla <kasha@cloudera.com>:

> Inline.
>
> > 1) Set the fix version for all a.b.c versions, where c > 0.
> > 2) For each major release line, set the lowest a.b.0 version.
> >
>
> Sounds reasonable.
>
>
> >
> > The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> > a.b.c versions, with alpha1 being the a.b.0 release.
> >
>
> Once 3.0.0 GA goes out, a user would want to see the diff from the latest
> 2.x.0 release (say 2.9.0).
>
> Are you suggesting 3.0.0 GA would have c = 5 (say) and hence rule 1 would
> apply, and it should show up in the release notes?
>
>
> >
> > As an example, if a JIRA was committed to branch-2.6, branch-2.7,
> branch-2,
> > branch-3.0.0-alpha1, and trunk, it could have fix versions of 2.6.5,
> 2.7.3,
> > 2.8.0, 3.0.0-alpha1. The first two fix versions come from application of
> > rule 1, and the last two fix versions come from rule 2.
> >
> > I'm very eager to move this discussion forward, so feel free to reach out
> > on or off list if I can help with anything.
> >
>
>
> I think it is good practice to set multiple fix versions. However, it might
> take the committers a little bit to learn.
>
> Since the plan is to cut 3.0.0 off trunk, can we just bulk edit to add the
> 3.0.0-alphaX version?
>
>
> >
> > Best,
> > Andrew
> >
>

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