Re: Fix version maintenance for 1.4.0

I can confirm there are a few things committed to branch-1 not in branch-1.4 now. Fix versions are set accordingly (1.5.0 is in the set, 1.4.0 is not) On Fri, Nov 10, 2017 at 5:38 AM, Sean Busbey wrote: > 1.5.0 needs to appear already since a) we need a place to target

Re: Fix version maintenance for 1.4.0

I see, thanks for the clarification. Best Regards, Yu On 10 November 2017 at 21:38, Sean Busbey wrote: > 1.5.0 needs to appear already since a) we need a place to target fixes > that we're booting out of 1.4.0 and b) branch-1 and branch-1.4 have > diverged so a fix in

Re: Fix version maintenance for 1.4.0

1.5.0 needs to appear already since a) we need a place to target fixes that we're booting out of 1.4.0 and b) branch-1 and branch-1.4 have diverged so a fix in one does not necessarily mean a fix is in the other. On Thu, Nov 9, 2017 at 11:50 PM, Yu Li wrote: > It would be a

Re: Fix version maintenance for 1.4.0

It would be a pain for user to judge whether a patch for 1.3.1 is included in 1.4.0 from the version number, they will have to get and compare the release timeline of 1.3.1 and 1.4.0. So I'm a big fun of the already taken action: "Now, 1.4.0 was dropped only if there is a fixversion 1.3.0 in the

Re: Fix version maintenance for 1.4.0

It is a good discussion. I had confusions in rare cases where I couldn't rely on the JIRA clearly if a fix was in a release. It will be really nice to explicitly document the implicit assumptions. Is there anything or change that committers need to do? For example, don't mark 'fixed in 1.5' on

Re: Fix version maintenance for 1.4.0

On Thu, Nov 9, 2017 at 12:22 PM, Mike Drob wrote: > By this same token, there are a lot of issues with fix version 2.0.0-alphaX > or -betaY and also 3.0.0 > > Should we drop the 3.0.0 from these? > > Yes (says the 2.0.0 RM). I've been doing this as I come across them. I filed

Re: Fix version maintenance for 1.4.0

Up to the branch2 RM I'd say. Can we have a separate discussion for that? I think this one is good. On Thu, Nov 9, 2017 at 12:22 PM, Mike Drob wrote: > By this same token, there are a lot of issues with fix version 2.0.0-alphaX > or -betaY and also 3.0.0 > > Should we drop the

Re: Fix version maintenance for 1.4.0

By this same token, there are a lot of issues with fix version 2.0.0-alphaX or -betaY and also 3.0.0 Should we drop the 3.0.0 from these? On Thu, Nov 9, 2017 at 1:42 PM, Andrew Purtell wrote: > > once 1.4.0 RC0 comes out, we need to include 1.5.0 because if RC0 passes, >

Re: Fix version maintenance for 1.4.0

> once 1.4.0 RC0 comes out, we need to include 1.5.0 because if RC0 passes, such an issue will actually be in 1.4.1 and not 1.4.0 Ok, I'll remember that. On Thu, Nov 9, 2017 at 11:40 AM, Sean Busbey wrote: > That all sounds correct. The one edge case is that when the .0

Re: Fix version maintenance for 1.4.0

That all sounds correct. The one edge case is that when the .0 release hasn't been cut yet but RCs exist, it's important to include in fix versions any releases that would need to be included if the current RC passed. e.g. once 1.4.0 RC0 comes out, we need to include 1.5.0 because if RC0 passes,

Re: Fix version maintenance for 1.4.0

Cool. Don't mean to suggest this is a change or new, just thinking through and writing down what I think I've observed and folks seem to be doing, which makes sense. I don't have the bandwidth at the moment to figure out the doc format and go through the process to create a patch, but if any of

Re: Fix version maintenance for 1.4.0

> Yes, those are the rules I applied. To clarify: Those are the rules I applied after going back and adding back fixversions such that the set {1.3.1, ...} becomes {1.4.0, 1.3.1, ...} as Sean suggested. Now, 1.4.0 was dropped only if there is a fixversion 1.3.0 in the set. And, 1.5.0 was dropped

Re: Fix version maintenance for 1.4.0

Or, in other words, an issue should have a fix version marked for: (a) first major version it's in (b) first minor version it's in of any major version before (a) (c) first patch version it's in of any minor version before (b) On Thu, Nov 9, 2017 at 11:17 AM, Dave Latham

Re: Fix version maintenance for 1.4.0

Yes, those are the rules I applied. While I was in there adjusting fixversions I noticed that generally we follow exactly that approach for numbering. I think we inherit it from Hadoop, because our old timers came from that community. Dave - Please consider submitting a patch for our online book

Re: Fix version maintenance for 1.4.0

+1 for making it as simple as possible to determine if a given fix is in a given release purely from the release numbers, without having to consult the dates of when branches were made or release candidates were built. I think the rules should be Fix version of X.Y.Z => fixed in all releases

Re: Fix version maintenance for 1.4.0

You mean put back the 1.4.0 fixversion for anything released in 1.3.1? I can do that. I don't have a strong opinion either way. Let me make a pass now. Any other suggestions? On Thu, Nov 9, 2017 at 6:15 AM, Sean Busbey wrote: > I'd like to try convincing you to just drop

Re: Fix version maintenance for 1.4.0

I only dropped 1.4.0 from fix versions if it went out in a released 1.3, so if there was a fix version of '1.3.1' or '1.3.0' then it was dropped, otherwise it was not. On Wed, Nov 8, 2017 at 10:05 PM, Stack wrote: > On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell

Re: Fix version maintenance for 1.4.0

I'd like to try convincing you to just drop issues that were in 1.3.0. I assume that 1.4 will become our new stable line. Suppose that I am running on our stable 1.2 release line. When considering an upgrade to 1.4.z, which CHANGES files do I have to read to get a sense of what I have to look out

Re: Fix version maintenance for 1.4.0

On Wed, Nov 8, 2017 at 4:31 PM, Andrew Purtell wrote: > You may notice I'm dropping '1.4.0' from fix versions wherever we have > something that went in to any 1.3.x. This is because I am basing the > CHANGES.txt changelog for 1.4.0 on the latest from branch-1.3, so anything

Fix version maintenance for 1.4.0

You may notice I'm dropping '1.4.0' from fix versions wherever we have something that went in to any 1.3.x. This is because I am basing the CHANGES.txt changelog for 1.4.0 on the latest from branch-1.3, so anything that went in on branch-1.3 will be included in the changelog at the correct point