Re: Setting JIRA fix versions for 3.0.0 releases

Sean gave me some pointers on using Java ACC, I've made a report using the script I've been working on at YETUS-445: http://home.apache.org/~wang/h3/report.html Invocation was something like this: -> % ~/dev/yetus/check-java-compatibility/checkjavacompatibility.py --annotation

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

hadoop.apache.org; >> hdfs-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org >> Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2) >> releases [Was Setting JIRA fix versions for 3.0.0 releases] >> >> I like the 3.0.0-alphaX approac

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

yarn-dev@hadoop.apache.org; > hdfs-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org > Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2) > releases [Was Setting JIRA fix versions for 3.0.0 releases] > > I like the 3.0.0-alphaX approach primarily for simpler

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

he.org; hdfs-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org Subject: Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases] I like the 3.0.0-alphaX approach primarily for simpler understanding of compatibility g

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I like the 3.0.0-alphaX approach primarily for simpler understanding of compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing because, it is not immediately clear that 3.0.0 and 3.1.0 could be incompatible in APIs. I am open to something like 2.98.x for alphas and 2.99.x for

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

On Thu, Aug 4, 2016 at 11:20 AM, Andrew Wang wrote: > Hi Konst, thanks for commenting, > > On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko > wrote: > >> 1. I probably missed something but I didn't get it how "alpha"s made >> their way into

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> I'm certainly open to alternate proposals for versioning and fix versions, > but to reiterate, I like this versioning since it imitates other enterprise > software. RHEL has versions like 6.2 Beta 2 and 7.0 Beta, so versions like > 3.0.0-alpha1 will be immediately familiar to end users.

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

On Thu, Aug 4, 2016 at 12:41 PM, Chris Douglas wrote: > I agree with Konst. The virtues of branching (instead of releasing > from trunk) and using the version suffix for the 3.x releases are lost > on me. Both introduce opportunities for error, in commits, in > consistent

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I agree with Konst. The virtues of branching (instead of releasing from trunk) and using the version suffix for the 3.x releases are lost on me. Both introduce opportunities for error, in commits, in consistent JIRA tagging, in packaging... We can mark stability on the website. If someone builds

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Hi Konst, thanks for commenting, On Wed, Aug 3, 2016 at 11:29 PM, Konstantin Shvachko wrote: > 1. I probably missed something but I didn't get it how "alpha"s made their > way into release numbers again. This was discussed on several occasions and > I thought the common

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

1. I probably missed something but I didn't get it how "alpha"s made their way into release numbers again. This was discussed on several occasions and I thought the common perception was to use just three level numbers for release versioning and avoid branding them. It is particularly confusing to

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

In the absence of further comments, I've pushed this text to a new "Release Versioning" page on the website. I think svnpubsub automatically builds and pushes for us now, but not 100% sure. Anyway, it seems like we can proceed with the 2.8.0 and 3.0.0-alpha1 version updates. I'm going to be on

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I've written up the proposal from my initial reply in a GDoc. I found one bug in the rules when working through my example again, and also incorporated Akira's correction. Thanks all for the discussion so far! https://docs.google.com/document/d/1vlDtpsnSjBPIZiWQjSwgnV0_Z6ZQJ1r91J8G0FduyTg/edit

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Inline. > >> 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

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Hi Junping, thanks for sharing your thoughts, inline, On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 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

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> > 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)

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

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

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

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. >

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Thanks Andrew for sharing your thoughts, It looks better if we can put multiple versions on the fix version, with that we can at least do some queries on JIRA to check the issues like "in branch-2.6.5 but not in branch-2.7.4". I still have a couple of questions: *1) How CHANGES.txt (or release

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I think I understand a bit better, though now I ask how this date is different from the release date. Based on the HowToRelease instructions, we set the release date to when the release vote passes. So, start of release vote vs. end of release vote doesn't seem that different, and these dates are

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> Andrew: I bet many would assume it's the release date, like how Ubuntu releases are numbered. Good point. Maybe I confuse you because of lack of explanation. I assume that "branch-cut off timing" mean the timing of freezing branch like when starting the release vote. It's because that the

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Thanks for replies Akira and Tsuyoshi, inline: Akira: Assuming 3.0.0-alpha1 will be released between 2.7.0 and 2.8.0, we > need to add 3.0.0-alphaX if 2.8.0 is in the fix versions of a jira and we > don't need to add 3.0.0-alphaX if 2.7.0 is in the fix versions of a jira. > Is it right? Yes,

[DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Hi Vinod, Thanks all guys for starting discussion! My suggestion is adding the date when branch cut is done: like 3.0.0-alpha1-20160724, 2.8.0-20160730 or something. Pros:-) It's totally ordered. If we have a policy such as backporting to maintainance branches after the date, users can find

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Thanks Vinod for forking the thread. Let me try and summarize what Allen and I talked about in the previous thread. Currently, we've been marking JIRAs with fix versions of both 2.6.x and 2.7.x. IIUC, the chronological ordering between these two lines is actually not important. If you're on

[DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Forking the thread to make sure it attracts enough eye-balls. The earlier one was about 3.0.0 specifically and I don’t think enough people were watching that. I’ll try to summarize a bit. # Today’s state of release numbering and ordering: So far, all the releases we have done, we have

Re: Setting JIRA fix versions for 3.0.0 releases

Hi all, I'm trying to generate JDiff for sub projects of Hadoop, some updates: *- Common*: JDiff cannot be generated , filed https://issues.apache.org/jira/browse/HADOOP-13428 and debugging that. - *HDFS*: It pointed to a older version (2.6.0), we need to upgrade it to the latest stable release

Re: Setting JIRA fix versions for 3.0.0 releases

+1 Thanks +Vinod > On Jul 26, 2016, at 7:39 AM, Wangda Tan wrote: > > lets try to use both jdiff and the new tool and compare results because this > is the first time with the new tool. > > Appreciate your time to help us about this effort!

Re: Setting JIRA fix versions for 3.0.0 releases

Hi Sean, Sorry I didn't make it clear, lets try to use both jdiff and the new tool and compare results because this is the first time with the new tool. Appreciate your time to help us about this effort! Thanks, Wangda Sent from my iPhone > On Jul 26, 2016, at 6:01 AM, Sean Busbey

Re: Setting JIRA fix versions for 3.0.0 releases

Just so I don't waste time chasing my tail, should I interpret this email and the associated JIRA as the PMC preferring I not spend volunteer time providing a compatibility breakdown as previously discussed? On Mon, Jul 25, 2016 at 7:54 PM, Wangda Tan wrote: > I just filed

Re: Setting JIRA fix versions for 3.0.0 releases

Yes, the Java API Compliance Checker allows specifying Annotations to pare down where incompatible changes happen. It was added some time ago based on feedback from the Apache HBase project. The limitations I've found are: 1) at least earlier versions only supported annotations at the class level

Re: Setting JIRA fix versions for 3.0.0 releases

Thanks Vinod+Wangda for the comments, Above, Allen and I discussed a proposal which I think is reasonable and also lines up well with our current approach. If you feel something is underspecified or needs improvement, please raise those points. We have been doing concurrent releases with the

Re: Setting JIRA fix versions for 3.0.0 releases

Hi Andrew, Please wait updating fix version for branch-2 committed tickets before we get a consensus on this. Updating fix versions for them could bring lots of troubles for on going two releases (2.7.3 / 2.8.0). Thanks, Wangda On Mon, Jul 25, 2016 at 11:02 AM, Andrew Wang

Re: Setting JIRA fix versions for 3.0.0 releases

I just filed ticket https://issues.apache.org/jira/browse/HADOOP-13423 to track running JDIFF on trunk and analyze results for Hadoop-common. I will work on that and keep the JIRA and this thread updated. We need to do the same work for YARN/MR/HDFS. On Mon, Jul 25, 2016 at 5:47 PM, Wangda Tan

Re: Setting JIRA fix versions for 3.0.0 releases

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

Re: Setting JIRA fix versions for 3.0.0 releases

Please don’t do this for 2.8.0 against 2.7.0 till we change our existing release ordering conventions. Till now, I made sure 2.8.0 only has issues that are not in 2.7.3 - per the 2.8.0-follows-2.7.3 convention. As part of the release process, I will fix the remaining tickets to follow this

Re: Setting JIRA fix versions for 3.0.0 releases

>> 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. I wasn’t talk about my irresistible urge to help (which of course is there : )) , it was about making sure enough

Re: Setting JIRA fix versions for 3.0.0 releases

Actually, I wouldn’t trust this report as it stands today at all. I quickly glanced the report, looking for what it highlights as incompatible. But the ones that I saw have private / visible for testing annotations. Other than acting as useless evidence for those lashing out on branch-2, this

Re: Setting JIRA fix versions for 3.0.0 releases

> On Jul 22, 2016, at 7:16 PM, Andrew Wang wrote: > > Does this mean you find our current system of listing a JIRA as being fixed > in both a 2.6.x and 2.7.x to be confusing? Nope. I'm only confused when there isn't a .0 release in the fix line. When I see

Re: Setting JIRA fix versions for 3.0.0 releases

Thanks for the input Allen, good perspective as always, inline: > From the perspective of an end user who is reading multiple > versions' listings at once, listing the same JIRA being fixed in multiple > releases is totally confusing, especially now that release notes are > actually

Re: Setting JIRA fix versions for 3.0.0 releases

From the perspective of an end user who is reading multiple versions' listings at once, listing the same JIRA being fixed in multiple releases is totally confusing, especially now that release notes are actually readable. "So which version was it ACTUALLY fixed in?" is going to be the

Re: Setting JIRA fix versions for 3.0.0 releases

> > >> 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

Re: Setting JIRA fix versions for 3.0.0 releases

On Thu, Jul 21, 2016 at 3:58 PM, Andrew Wang 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

Re: Setting JIRA fix versions for 3.0.0 releases

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

RE: Setting JIRA fix versions for 3.0.0 releases

[mailto:andrew.w...@cloudera.com] Sent: Friday, July 22, 2016 3:33 AM To: Vinod Kumar Vavilapalli <vino...@apache.org> Cc: common-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org; yarn-dev@hadoop.apache.org Subject: Re: Setting JIRA fix versions for 3.0.0 releases I really, reall

Re: Setting JIRA fix versions for 3.0.0 releases

On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli 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

Re: Setting JIRA fix versions for 3.0.0 releases

> 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

Re: Setting JIRA fix versions for 3.0.0 releases

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. I'm not too worried

Re: Setting JIRA fix versions for 3.0.0 releases

The L & N fixes just went out, I’m working to push out 2.7.3 - running into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0. Like I requested before in one of the 3.x threads, can we just line up 3.0.0-alpha1 right behind 2.8.0? That simplifies most of this confusion, we can

Setting JIRA fix versions for 3.0.0 releases

Hi all, Since we're planning to spin releases off of both branch-2 and trunk, the changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This is because historically, we've only set 2.x fix versions, and 2.8.0 and 2.9.0 and etc have not been released. So there's a whole bunch of