I hacked on it some more and yes, it’s very easy to detect:
* type of jira (improvement, bug, new feature, wish, task, sub-task)
* incompatible or not (regardless of type)
* reviewed or not (regardless of type)
A key question is what to do about tasks, sub-tasks, and wishes. I
haven’t tried yet, but I’m fairly confident that sub-tasks list what the parent
is, so those can probably be handled specially. We either need to list tasks
and wishes as what they are or, in the script, turn them into something else.
Also added some sorting to it based upon number. I’m not sure what
order we’re getting from JIRA now. Last updated time is going to be wonky with
all the changes I did. I didn’t look to see if there was a ‘resolve date’.
It should be noted that the release note script already created
different files: a master one and one for each project. That functionality was
kept but I just shared the master one because it was easier. ;)
https://github.com/aw-altiscale/hadoop/blob/trunk/dev-support/changes.py is the
current version if someone wants to look at it.
We do need to have a talk about 3.x though. Looking over the list, it
would appear that a lot of (what became) early 2.x JIRAs were marked as Fixed
against 3.x. Probably 2/3’rd of the JIRAs showing up! I think it may be safe
to just say “everything before date X should be set to 2.x”, but I’m not sure
of what that date would be. Doing that would chop the 3.x change list down to
a much more realistic size, esp when compared to the manual changes file.
On Sep 4, 2014, at 4:38 AM, Steve Loughran <ste...@hortonworks.com> wrote:
> is there any way of isolating compatible/incompatible changes, & new
> features?
>
> I know that any change is potentially incompatible —but it is still good to
> highlight the things we know are likely to cause trouble
>
>
> On 4 September 2014 02:51, Allen Wittenauer <a...@altiscale.com> wrote:
>
>> Nothing official or clean or whatever, but just to give people an idea of
>> what an auto generated CHANGES.txt file might look like, here are some
>> sample runs of the hacky thing I built, based upon the fixVersion
>> information. It doesn't break it down by improvement, etc. Also, the name
>> on the end is the person who the JIRA is assigned. If it is unassigned,
>> then it comes out blank. It's interesting to note that in the 2.5.1 notes,
>> it does appear to have caught a commit missing from the changes.txt….
>>
>> 2.5.1: http://pastebin.com/jXfz5wXz
>>
>> 2.6.0: http://pastebin.com/5nkSsU18
>>
>> 3.0.0: http://pastebin.com/3Ek4tP8d
>>
>> One thing I didn't do was append the previous versions onto these files,
>> which is what I'd expect to happen.
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
