On Thu, Jul 21, 2016 at 3:58 PM, Andrew Wang <andrew.w...@cloudera.com> wrote:
> Thanks for the input Vinod, inline: > > > > Similarly the list of features we are enabling in this alpha would be > good > > - may be update the Roadmap wiki. Things like classpath-isolation which > > were part of the original 3.x roadmap are still not done. > > > > I already updated the website release notes at HADOOP-13383. I can update > the Roadmap wiki and break out what's new in alpha1 too, thanks for the > reminder. > > > > > * Community bandwidth isn't zero-sum. This particularly applies to > > people working on features that are only present in trunk, like EC, shell > > script rewrite, etc. > > > > > > A bunch of us are going to be busy with finishing 2.8.0. It isn’t > > zero-sum, but it predicates those of us involved with 2.8.0 from looking > at > > it, even though we are very interested in doing so. > > > > There's a plan for more 3.0.0 alphas, so there's still time to help out > before things settle down for beta. If 2.8.0 is ready to go, it should > happen before even alpha2. > > > > > Obviously, I am not making the case that this issue won’t happen ever. In > > fact, this already happened with the parallel 2.6.x and 2.7.x releases. > And > > we precisely avoided major confusion there by lining up 2.7.2 behind > 2.6.3 > > etc. > > > > Could you clarify how lining up releases differently avoids the fix version > issue? > > What we've been doing is something like "one fix version per active release > line". Since we've revived 3.x as a release line, it seems like a lot of > JIRAs need 3.x fix versions now. > > As an aside, I honestly don't know how to interpret the fix version > instructions on the HowToCommit wiki. They don't seem to match up with what > we actually do in practice. > I am also not quite sure I understand the rationale of what's in the HowToCommit wiki. Assuming the semantic versioning (http://semver.org) as our baseline thinking, having concurrent release streams alone breaks the principle. And that is *regardless of* how we line up individual releases in time (2.6.4 v. 2.7.3). Semantic versioning means 2.6.z < 2.7.* where * is any number. Therefore, the moment we have any new 2.6.z release after 2.7.0, the rule is broken and remains that way. Timing of subsequent releases is somewhat irrelevant. >From a practical standpoint, I would love to know whether a certain patch has been backported to a specific version. Thus, I would love to see fix version enumerating all the releases that the JIRA went into. Basically the more disclosure, the better. That would also make it easier for us committers to see the state of the porting and identify issues like being ported to 2.6.x but not to 2.7.x. What do you think? Should we revise our policy? > > Best, > Andrew >
