[ https://issues.apache.org/jira/browse/HADOOP-11731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)