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 chan
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 avoi
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 abou
> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still
> have the issue of things committed for 2.9.0 that will be appearing for the
> first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs,
> it's only incrementally more work to also fix up 2.8 and other unrel
> 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 a
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 branch-3.0.0-alpha1 is ready
--
From: Andrew Wang [mailto:andrew.w...@cloudera.com]
Sent: Friday, July 22, 2016 3:33 AM
To: Vinod Kumar Vavilapalli
Cc: common-dev@hadoop.apache.org; mapreduce-...@hadoop.apache.org;
yarn-...@hadoop.apache.org
Subject: Re: Setting JIRA fix versions for 3.0.0 releases
I really, really want
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
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 the original 3.x roadmap are
>
>
>> 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 rele
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
I’ve been using jdiff simply because of a lack of alternative.
If you’ve had experience with tool [1], if you think it serves our purpose, and
if you can spare some time, that’ll be greatly appreciated. I can also pitch in
with whatever help is needed.
I think we should pick one of 2.6.3 or 2.7
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 reada
> 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 2.6.x and 2.7.x I know tha
If I don't hear otherwise, I'd like to go ahead and do the bulk fix version
update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
tomorrow in case there's more discussion. If any one is willing to help
review my script and JIRA queries, that'd also be great.
I can also do the 2.
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 wo
>> 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 eye-ba
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 same
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 j
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 wr
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
wrote:
> If I don't h
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 2.6.
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
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 ticket https://issues.a
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 wrote:
>
>
+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!
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 (p
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 org.apache.hadoop.
I've taken a look at the Common and HDFS compat issues.
* A bunch of them are from the known removals of the deprecated Metrics 1
and RCC. JACC understands and can filter @Deprecated annotations, but
HADOOP-7266 isn't in 2.7.2, and apparently JACC doesn't look at the class
annotation when telling
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 follow
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 that
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 2.6.1,
Thanks Vinod and Andrew for the summary.
> Here's an attempt at encoding this policy as a set of rules for
setting fix
> versions (credit to Allen):
>
> 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.
Assuming 3.0.0-al
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, cor
> 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 relea
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 s
> I think I understand a bit better, though now I ask how this date is
> different from the release date.
OIC. I also assume that the freezing branch cannot include the changes
between freezing date and the release date. This is for strict
ordering to ensure which is the newer. If we have lots ma
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 n
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
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 t
>
> 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)
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 make life easier.
>
> > The
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
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
Pi
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 vac
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
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 perception was to use jus
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 a
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 JIRA tagging, in packagi
> 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. Conversel
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 release numbers again. This was discussed on severa
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 be
-...@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 guarantees. Calling 3.0.0 alpha
e.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 guarantees. Ca
;> Thanks,
>>
>> Junping
>>
>> From: Karthik Kambatla
>> Sent: Monday, August 08, 2016 6:54 PM
>> Cc: common-dev@hadoop.apache.org; yarn-...@hadoop.apache.org;
>> hdfs-...@hadoop.apache.org; mapreduce-...@hadoop
55 matches
Mail list logo
