Hi Junping, thanks for sharing your thoughts, inline, On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 <junping...@apache.org> wrote:
> 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). > Based on the website, 2.7.0 immediately followed 2.6.0, so that's not quite accurate. However your point does hold for 2.5.2 -> 2.6.0. Vinod already described this earlier, where for a while we only had a single chronological release line. Now though, we have the concurrent 2.6.x and 2.7.x release lines, which do fix versions independently. One goal here is a versioning scheme that extends this concurrency to additional major and minor releases, i.e. 2.8 and 3.0. It doesn't make sense to have a global ordering of releases, since not all patches belong in all branches. It also poses additional coordination cost for release management, particularly since it's hard to predict release timings. Another goal is a scheme that is easy for users to understand. I believe the above scheme accurately encodes the versioning system used by most other enterprise software. > 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. > > These rules seem to require a high degree of coordination when it comes to release ordering, but one goal is to reduce coordination. For example, the 2.7.0 notes say "Production users should wait for a 2.7.1/2.7.2 release." We didn't know in advance if 2.7.1 or 2.7.2 would be the stable release. We also don't know the release ordering of 2.7.4 and 2.8.0. Given the uncertainty around release timing and stability, it's advantageous to avoid basing versioning on these two pieces of information. With these rules, a changes in stability or release ordering means we need to update JIRA fix versions. I also didn't quite follow your example, since I assume that 2.8.0 will *not* be marked stable similar to how 2.7.0 is not stable. If this is true, does rule 1 take precedence and we would base 3.0.0-alpha1 off of 2.7.4 (the latest stable release)? That seems confusing given the presence of 2.8.0. Could you elaborate on what you see as the advantages of this scheme from a user POV? It seems like users now need to be aware of the total ordering and also stability of releases to know what changelogs to read. And as described previously, it's not how other enterprise software versioning works. > > 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. > > We already need to backport to many branches, setting some more fix versions doesn't change that. Setting more fix versions is also not related to review bandwidth, particularly in this case since things normally land in trunk first. It's also not related to the number of concurrent releases, since release-related effort is not zero-sum. > 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. > These are the definitions of "alpha" and "beta" used leading up to the 2.2 GA release, so it's not something new. These are also the normal industry definitions. Alpha means no API compatibility guarantees, early software. Beta means API compatible, but still some bugs. If anything, we never defined the terms "alpha" and "beta" for 2.x releases post-2.2 GA. The thinking was that everything after would be compatible and thus (at the least) never alpha. I think this is why the website talks about the 2.7.x line as "stable" or "unstable" instead, but since I think we still guarantee API compatibility between 2.7.0 and 2.7.1, we could have just called 2.7.0 "beta". I think this would be good to have in our compat guidelines or somewhere. Happy to work with Karthik/Vinod/others on this. > 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. > > While we're still in alpha for 3.0.0, there's no need for a separate 4.0.0 version since there's no guarantee of API compatibility. I plan to cut a branch-3 for the beta period, at which point we'll upgrade trunk to 4.0.0-alpha1. This is something we discussed on another mailing list thread. Best, Andrew
