Source code has been deleted from branch-2. Thanks Akira for taking this up!
Jonathan Hung
On Thu, Apr 16, 2020 at 11:40 AM Jonathan Hung wrote:
> Makes sense. I've cherry-picked the commits in branch-2 that were missed
> in branch-2.10.
>
> Jonathan Hung
>
>
> On Wed, Apr 15, 2020 at 2:25 AM
Makes sense. I've cherry-picked the commits in branch-2 that were missed in
branch-2.10.
Jonathan Hung
On Wed, Apr 15, 2020 at 2:25 AM Akira Ajisaka wrote:
> Hi folks,
>
> I am still seeing some changes are being committed to branch-2.
> I'd like to delete the source code from branch-2 to
Hi folks,
I am still seeing some changes are being committed to branch-2.
I'd like to delete the source code from branch-2 to avoid mistakes.
https://issues.apache.org/jira/browse/HADOOP-16988
-Akira
On Wed, Jan 1, 2020 at 2:38 AM Ayush Saxena wrote:
> Hi Jim,
> Thanx for catching, I have
Hi Jim,
Thanx for catching, I have configured the build to run on branch-2.10.
-Ayush
On Tue, 31 Dec 2019 at 22:50, Jim Brennan
wrote:
> It looks like QBT tests are still being run on branch-2 (
> https://builds.apache.org/view/H-L/view/Hadoop/job/hadoop-qbt-branch2-java7-linux-x86/),
> and
It looks like QBT tests are still being run on branch-2 (
https://builds.apache.org/view/H-L/view/Hadoop/job/hadoop-qbt-branch2-java7-linux-x86/),
and they are not very helpful at this point.
Can we change the QBT tests to run against branch-2.10 instead?
Jim
On Mon, Dec 23, 2019 at 7:44 PM
Thank you, Ayush.
I understand we should keep branch-2 as is, as well as master.
-Akira
On Mon, Dec 23, 2019 at 9:14 PM Ayush Saxena wrote:
> Hi Akira
> Seems there was an INFRA ticket for that. INFRA-19581,
> But the INFRA people closed as wont do and yes, the branch is protected,
> we
Hi Akira
Seems there was an INFRA ticket for that. INFRA-19581,
But the INFRA people closed as wont do and yes, the branch is protected, we
can’t delete it directly.
Ref: https://issues.apache.org/jira/browse/INFRA-19581
-Ayush
> On 23-Dec-2019, at 5:03 PM, Akira Ajisaka wrote:
>
> Thank
Thank you for your work, Jonathan.
I found branch-2 has been unintentionally pushed again. Would you remove it?
I think the branch should be protected if possible.
-Akira
On Tue, Dec 10, 2019 at 5:17 AM Jonathan Hung wrote:
> It's done. The new commit chain is: trunk -> branch-3.2 ->
It's done. The new commit chain is: trunk -> branch-3.2 -> branch-3.1 ->
branch-2.10 -> branch-2.9 -> branch-2.8 (branch-2 no longer exists, please
don't try to commit to it)
Completed procedure:
- Verified everything in old branch-2.10 was in old branch-2
- Delete old branch-2.10
-
FYI, starting the rename process, beginning with INFRA-19521.
Jonathan Hung
On Wed, Nov 27, 2019 at 12:15 PM Konstantin Shvachko
wrote:
> Hey guys,
>
> I think we diverged a bit from the initial topic of this discussion, which
> is removing branch-2.10, and changing the version of branch-2
Hey guys,
I think we diverged a bit from the initial topic of this discussion, which
is removing branch-2.10, and changing the version of branch-2 from
2.11.0-SNAPSHOT to 2.10.1-SNAPSHOT.
Sounds like the subject line for this thread "Making 2.10 the last minor
2.x release" confused people.
It is
On Thu, Nov 21, 2019 at 11:49 PM Jonathan Hung wrote:
> Thanks for the detailed thoughts, everyone.
>
> Eric (Badger), my understanding is the same as yours re. minor vs patch
> releases. As for putting features into minor/patch releases, if we keep the
> convention of putting new features only
Thanks for the detailed thoughts, everyone.
Eric (Badger), my understanding is the same as yours re. minor vs patch
releases. As for putting features into minor/patch releases, if we keep the
convention of putting new features only into minor releases, my assumption
is still that it's unlikely
Hello all,
Is it written anywhere what the difference is between a minor release and a
point/dot/maintenance (I'll use "point" from here on out) release? I have
looked around and I can't find anything other than some compatibility
documentation in 2.x that has since been removed in 3.x [1] [2]. I
Hi Konstantin,
Sure, I understand those concerns. On the other hand, I worry about the
stability of 2.10, since we will be on it for a couple of years at least. I
worry
that some committers may want to put new features into a branch 2 release,
and without a branch-2, they will go directly into
Hi Eric,
We had a long discussion on this list regarding making the 2.10 release the
last of branch-2 releases. We intended 2.10 as a bridge release between
Hadoop 2 and 3. We may have bug-fix releases or 2.10, but 2.11 is not in
the picture right now, and many people may object this idea.
I
Thanks Eric for the comments - regarding your concerns, I feel the pros
outweigh the cons. To me, the chances of patch releases on 2.10.x are much
higher than a new 2.11 minor release. (There didn't seem to be many people
outside of our company who expressed interest in getting new features to
+1, thanks Jonathan for bringing this up!
On Fri, Nov 15, 2019 at 11:41 AM epa...@apache.org
wrote:
> Thanks Jonathan for opening the discussion.
>
> I am not in favor of this proposal. 2.10 was very recently released, and
> moving to 2.10 will take some time for the community. It seems
Thanks Jonathan for opening the discussion.
I am not in favor of this proposal. 2.10 was very recently released, and moving
to 2.10 will take some time for the community. It seems premature to make a
decision at this point that there will never be a need for a 2.11 release.
-Eric
On
I'm in support of this. The current scheme is confusing, and as you
mentioned, is making the backport strategy less clear. It reminds me of the
branch-2.8 vs. branch-2 (destined for 2.9) days when various fixes would
make it into one or the other.
One other action item would be to do a quick
Some other additional items we would need:
- Mark all fix-versions in YARN/HDFS/MAPREDUCE/HADOOP from 2.11.0 to
2.10.1
- Remove 2.11.0 as a version in these projects
Jonathan Hung
On Thu, Nov 14, 2019 at 6:51 PM Jonathan Hung wrote:
> Hi folks,
>
> Given the release of 2.10.0, and
21 matches
Mail list logo
