[Koha-bugs] [Bug 22890] Add a chronological changelog

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22890

--- Comment #7 from Julian Maurice <julian.maurice at biblibre.com> ---
(In reply to Jonathan Druart from comment #6)
> I like the "tags" on https://keepachangelog.com/en/1.0.0/, like "Added",
> "Deprecated", etc.
> 
> It would be great to have some like "new modules", "new method", "new api
> route", "deprecated", "new/rm/mv sysprefs", "new table/column", etc.
> 
> So a single entry "feature foo" could have several tags.
> 
> We could have that at the end of the "Text to go in the release notes", like:
> 
> """
> This is a release note for feature foo that bring useful stuffs.
> %%%%%%%%%%%%%% # a separator line
> [Add pref]YetAnotherPref
> [Add DB table]a_new_db_table
> """
> 
> The changelog could then be built using that and make the DB changes (or any
> other type of changes) eyeballed easily.

Why not add this directly in the patch ?
Following the keepachangelog convention we could have:

ChangeLog.md

  ### Added
  - This is a release note for feature foo that bring useful stuffs.

  ### Sysprefs
  - Add new syspref YetAnotherPref

  ### Technical/Dev
  - Add new database table a_new_db_table


I see several benefits over using the bugzilla field:
- Documentation of the change is close to the code. It can be part of the QA
process to review that doc.
- No additional tooling needed. We can even remove some tools because we won't
need to generate release notes at release time.
- Having to write in a specific format ([tag]description) that would be parsed
by a script is error-prone and errors would be discovered only at release time.
- ChangeLog is always up to date in master, making it easy to see what changed
since the latest stable version.
- It would be easy to see what changed between 2 commits, which can be really
helpful when rebasing patches.

The downside is that it will cause git conflicts, so we should probably have to
do something similar to updatedatabase (atomicupdate)

We can also consider having a DeveloperChangeLog.md to avoid polluting the main
changelog too much with technical details.

-- 
You are receiving this mail because:
You are watching all bug changes.