[ 
https://issues.apache.org/jira/browse/LUCENE-8883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16880981#comment-16880981
 ] 

Adrien Grand commented on LUCENE-8883:
--------------------------------------

I just looked at the section names that we used at least 10 times in the 
changelog:

{noformat}
     55 API Changes
     53 Bug Fixes
     52 Optimizations
     46 Build
     41 Bug fixes
     37 New Features
     25 Documentation
     24 Other
     21 Changes in Runtime Behavior
     19 Changes in backwards compatibility policy
     15 New features
     15 Improvements
     14 Changes in runtime behavior
     10 Tests
{noformat}

Maybe your patch should rename "Other Changes" to "Other" which seems to be 
what we have used historically, and maybe also add "API Changes" and 
"Optimizations", which seem pretty popular?

Maybe we could specialize bugfix versions and only introduce a "Bug Fixes" 
section in that case?

bq. Also I didn't add "(No changes)"; seems needless / self-evident.

I think it helps clarify since it is very uncommon to release software without 
any changes. We could do it only for new bugfix releases if you think that 
helps since I think those are the only ones that we ever released without new 
changes.

> CHANGES.txt: Auto add issue categories on new releases
> ------------------------------------------------------
>
>                 Key: LUCENE-8883
>                 URL: https://issues.apache.org/jira/browse/LUCENE-8883
>             Project: Lucene - Core
>          Issue Type: Task
>          Components: general/build
>            Reporter: David Smiley
>            Assignee: David Smiley
>            Priority: Minor
>         Attachments: LUCENE-8883.patch
>
>
> As I write this, looking at Solr's CHANGES.txt for 8.2 I see we have some 
> sections: "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes".  
> There is no "Improvements".... so no surprise here, the New Features category 
> has issues that ought to be listed as such.  I think the order vary as well.  
> I propose that on new releases, the initial state of the next release in 
> CHANGES.txt have these sections.  They can easily be removed at the upcoming 
> release if there are no such sections, or they could stay as empty.  It seems 
> addVersion.py is the code that sets this up and it could be enhanced.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to