The release process is what handles updating the CHANGES and UPGRADE.txt files now. Whenever a release is being made, everything in the staging directories is taken and added to the beginning of the corresponding file. Everything that has the same subject (e.g, "res_pjsip") will be grouped under one section and separated by asterisks, exactly how it has been done in the past. The directories will then be cleaned up and the commit will be pushed in along with everything else. Easy as that!
During the release process, if something goes wrong, the working directory that the release is being done from may need to be reset. You may be able to just do a
on the working directory, but do double check and make sure everything looks the way you would expect it to. There's a chance you may need to reset the HEAD, so check commit history as well!
Here's an example of what one of these directories might look like before a release:
Subject: res_pjsip Subject: Core Obviously this is just an example and when you write a description it should be way better than this. But you get the idea!
The "Subject: res_pjsip" line is considered a special header and is case sensitive. This is what the script uses to determine what goes where and what content belongs to. Other headers can be added in the future this way, following the subject header.
These changes will be separated into a different storage structure and added BEFORE the other changes, so that the new stuff is seen first!
Running it Manually
Sometimes, it may be necessary to make these changes manually. Master is one such example, since the mainline branch will never be "master". There could also be a scenario where the branch to be released is already in existence, in which case you would need to run the script on this branch (for example, if releasing 16.3.0, this branch would need to be updated; 16 would get updated during the mkrelease script). Luckily, all you have to do is run a couple of scripts to accomplish this:
someone@justanexample:/path/to/repotools/# ./process-staging-changes -s 16.2.0 -e 16.3.0 # Done! Check /tmp/asterisk and make sure everything looks right. Then run 'commit-staging-changes -v 16.3.0 -b <current_branch>.'. someone@justanexample:/path/to/repotools/# ./commit-staging-changes -v 16.3.0 -b 16
Both of these scripts take an optional parameter (-l / --local-root). This works the same way as in the mkrelease script. If you're using a directory that's not the default (/tmp), you MUST specify this the path with this option.
process-staging-changes script will take all files in the doc/CHANGES-staging and doc/UPGRADE-staging directories, add their contents to the CHANGES and UPGRADE.txt files, and then remove those files.
commit-staging-changes script will commit ALL changes in the working directory with the commit message "Update CHANGES and UPGRADE.txt for <version>".