Summary:	ASTERISK-28111: build: CHANGES/UPGRADE are irritating to work with.
Reporter:	Corey Farrell (coreyfarrell)	Labels:
Date Opened:	2018-10-16 04:21:42	Date Closed:	2019-04-16 10:54:13
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Core/BuildSystem
Versions:	GIT	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	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.
Comments:	By: Asterisk Team (asteriskteam) 2018-10-16 04:21:44.189-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Friendly Automation (friendly-automation) 2019-04-16 10:54:14.209-0500 Change 10943 merged by Benjamin Keith Ford: build: Revise CHANGES and UPGRADE.txt handling. [https://gerrit.asterisk.org/c/asterisk/+/10943|https://gerrit.asterisk.org/c/asterisk/+/10943] By: Friendly Automation (friendly-automation) 2019-04-16 10:54:25.932-0500 Change 10944 merged by Benjamin Keith Ford: build: Revise CHANGES and UPGRADE.txt handling. [https://gerrit.asterisk.org/c/asterisk/+/10944|https://gerrit.asterisk.org/c/asterisk/+/10944] By: Friendly Automation (friendly-automation) 2019-04-16 10:54:43.601-0500 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]