[asterisk-bugs] [JIRA] (ASTERISK-28111) build: CHANGES/UPGRADE are irritating to work with.

[Friendly Automation (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=246922#comment-246922 ] 

Friendly Automation commented on ASTERISK-28111:
------------------------------------------------

Change 10945 merged by Benjamin Keith Ford:
build: Revise CHANGES and UPGRADE.txt handling.

[https://gerrit.asterisk.org/c/asterisk/+/10945|https://gerrit.asterisk.org/c/asterisk/+/10945]

> build: CHANGES/UPGRADE are irritating to work with.
> ---------------------------------------------------
>
>                 Key: ASTERISK-28111
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28111
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Core/BuildSystem
>    Affects Versions: GIT
>            Reporter: Corey Farrell
>            Severity: Minor
>
> When we make changes that are breaking or otherwise of significant note we have to record them in CHANGES/UPGRADE files.  This is extremely annoying due to every modification of these files conflicting with the others.  This ticket is to propose a solution.  I won't have time to work on this soon but if nobody else gets around to it eventually I'll take a crack at it.  Either way I think this is annoying enough that it is a bug in 'the process'.
> Proposed new process:
> 1. We create two folders, {{docs/changes/}} and {{docs/upgrade/}}.
> 2. If someone has to add an entry to CHANGES they instead create a new file in {{docs/changes/}}.
> 3. All files (or maybe \*.txt) in these folders are processed and the CHANGES/UPGRADE files are expanded before a release branch is created, processed files are removed.
> These steps would be taken before the existing release process.  So when creating a new release branch (say 16.1), these steps would occur first, the updates to CHANGES/UPGRADE would be merged into 16 before 16.1 is created.  Changes made between 16.1.0-rc1 and 16.1.0-rc2 would be processed and the CHANGES/UPGRADE files would be modified in the 16.1 branch.
> My hope for this ticket is that other will look at it and maybe think of things I'm missing.  Maybe the changes files should support tags that are not transferred to the CHANGES/UPGRADE files but say 'AMI-Bump: Feature' or similar to instruct the release process to bump the AMI version.  I have not given much thought to the formatting that would be used in the individual change files.



--
This message was sent by Atlassian JIRA
(v6.2#6252)