> On May 28, 2015, at 4:13 PM, James Peach <jpe...@apache.org> wrote:
>
>
>> On May 28, 2015, at 9:09 AM, Phil Sorber <sor...@apache.org> wrote:
>>
>> There was some discussion in IRC about removing the CHANGES file. It is
>> generally disliked and we have JIRA release notes that serve a similar
>> purpose. Here is an example of JIRA release notes for 6.0.0:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310963&version=12324897
>>
>> We also have `git log` which can be displayed in a way decent enough to
>> stand in for the CHANGES file.
>>
>> It was pointed out that we should still include something in the tarballs
>> that had the list of changes for posterity in case JIRA or git history is
>> ever lost. It was then proposed that we simply add a step to `make rel`
>> that will take the git shortlog and include it in a file called CHANGES
>> that only exists in the tarballs. Here is an open JIRA issue for that
>> effort:
>>
>> https://issues.apache.org/jira/browse/TS-3644
>>
>> How does everyone feel about this idea? Is anyone out there using the
>> CHANGES file?
>
> Some kind of changelog should be shipped in the source release to make it
> simple for people to figure out what went on in the release. Bonus points for
> shipping release notes too!
I’m +1 on eliminating the manual process of maintaining a CHANGES file. I’d
recommend that if we do so, we make this change for the v6.0.0 release and
going forward.
I think we could automate this, such that we generate something that *looks*
like (or similar to) our current CHANGES file, but using the Jira “Release
Notes” as the source. There are APIs for queuing Jira via REST APIs, we could
probably use that. Adding this to e.g. “make rel” would not be particularly
complex.
Now, what I have had to do in the past is to make sure the “Summary”, version
information, bug type etc. for each Jira on each release is correct and up to
date. This is a very tedious task to say the least. I’d urge everyone who is
filing (and resolving!) Jira’s to make sure things are correct. This includes
- Proper Summary
- Correct (appropriate) “Type” (such as “Bug” vs “Improvement” vs “New
feature”)
- Correct Fix Version (or no fix version, if closed as invalid/won’t
fix/dupe etc.)
- Correct Component (e.g. “Plugin” vs “HTTP/2” etc.)
I think the RMs will still comb through this before making a new release, but
I’m hoping that if we are going to use Jira as the canonical “CHANGES” system,
that everyone helps out and makes the information as correct and useful as
possible.
Cheers,
— Leif
