[
https://issues.apache.org/jira/browse/HADOOP-11731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14387519#comment-14387519
]
Allen Wittenauer edited comment on HADOOP-11731 at 3/30/15 10:20 PM:
-
That isn't quite how the current relnotes.py code works. When you provide a
previousVer or let it autodecrement to figure out what the previous release
was, it puts at the top of the file Changes since release [previous version]:
... and that's it. It doesn't do anything fancy like print a separate section
for every release it can calculate.
This code base doesn't even do that. It jettisons the whole since release x
thing. I take the view that our changes files is way too large on a per release
basis vs. what we did pre-1.x. Putting multiple releases in a single file is
too much information at one time.
So if that line is removed and we don't need to know what the previous release
was, there's no reason to even try to parse the version number, except for
maybe sorting purposes. It really is mostly useless code.
(FWIW: This does mean that x.0.0 releases present some special challenges for
both the old and new code. If 2.8.0 is declared dead, then when 3.0.0 is
built, it needs to get passed both 3.0.0 and 2.8.0 to merge all the changes
together. Removing 2.8.0 from JIRA doesn't work because branch-2 does have
those changes committed. The only other way to do this is to set the fix
version to include both, similarly to how one would do it for multiple,
concurrent releases. Luckily, this should only happen a few times, at the
most, and are clearly an edge case.)
Yes, I've spent too much time studying and thinking about these issues over the
past few months. lol
was (Author: aw):
That isn't quite how the current relnotes.py code works. When you provide a
previousVer or let it autodecrement to figure out what the previous release
was, it puts at the top of the file Changes since release [previous version]:
... and that's it. It doesn't do anything fancy like print a separate section
for every release it can calculate.
This code base doesn't even do that. It jettisons the whole since release x
thing. I take the view that our changes files is way too large on a per release
basis vs. what we did pre-1.x. Putting multiple releases in a single file is
too much information at one time.
So if that line is removed and we don't need to know what the previous release
was, there's no reason to even try to parse the version number, except for
maybe sorting purposes. It really is mostly useless code.
(FWIW: This does mean that x.0.0 releases present some special challenges for
both the old and new code. If 2.8.0 is declared dead, then when 3.0.0 is
built, it needs to get passed both 3.0.0 and 2.8.0 to merge all the changes
together. Removing 2.8.0 from JIRA doesn't work because branch-2 does have
those changes committed. The only other way to do this is to set the fix
version to conclude both, similarly to how one would do it for multiple,
concurrent releases. Luckily, this should only happen a few times, at the
most, and are clearly an edge case.)
Yes, I've spent too much time studying and thinking about these issues over the
past few months. lol
Rework the changelog and releasenotes
-
Key: HADOOP-11731
URL: https://issues.apache.org/jira/browse/HADOOP-11731
Project: Hadoop Common
Issue Type: New Feature
Components: documentation
Affects Versions: 3.0.0
Reporter: Allen Wittenauer
Attachments: HADOOP-11731-00.patch, HADOOP-11731-01.patch,
HADOOP-11731-03.patch, HADOOP-11731-04.patch, HADOOP-11731-05.patch
The current way we generate these build artifacts is awful. Plus they are
ugly and, in the case of release notes, very hard to pick out what is
important.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
