This PR tries to facilitate and improve the action of making releases (both development releases and official releases) in the RxPlayer:
[x] For official releases: a new scripts/make-official-release.sh script was added.
Before, the steps to make one were mainly manual and detailed in doc/contributing/releases.md.
Doing those steps manually was error-prone and stressful (e.g. of making by mistake a tag+release on GitHub's interface before pushing the related dev, or forgetting to update the CHANGELOG.md etc.)
The script performs the same steps, with most of it automatized. For those that cannot be automatized easily (e.g. looking at our CI's result on GitHub, checking that the API documentation and demo works as expected etc.), the script will pause, tell you what you need to do manually and propose an input to continue once it's done.
I also added some text on each of those "pause" to indicate what to do if you wanted to abort at that point. You will then be able to re-launch the script later when you're ready.
[x] Add verification in all those scripts whether the version's name is already taken either as a git's branch or as an npm release (may also do as a git tag in the future) and abort in the beginning if it's the case.
[x] Automatically pre-construct the CHANGELOG,md file each time a new release (dev like official) is done.
This would be done by checking merge requests since the last CHANGELOG.md change when the user calls a script to make a new release. User intervention on this changelog will be asked after this (e.g. to "categorize" those change proposal into features, bug fixes and so on).
This PR tries to facilitate and improve the action of making releases (both development releases and official releases) in the RxPlayer:
[x] For official releases: a new
scripts/make-official-release.shscript was added.Before, the steps to make one were mainly manual and detailed in
doc/contributing/releases.md.Doing those steps manually was error-prone and stressful (e.g. of making by mistake a tag+release on GitHub's interface before pushing the related dev, or forgetting to update the CHANGELOG.md etc.)
The script performs the same steps, with most of it automatized. For those that cannot be automatized easily (e.g. looking at our CI's result on GitHub, checking that the API documentation and demo works as expected etc.), the script will pause, tell you what you need to do manually and propose an input to continue once it's done.
I also added some text on each of those "pause" to indicate what to do if you wanted to abort at that point. You will then be able to re-launch the script later when you're ready.
[x] Add verification in all those scripts whether the version's name is already taken either as a git's branch or as an npm release (may also do as a git tag in the future) and abort in the beginning if it's the case.
[x] Automatically pre-construct the
CHANGELOG,mdfile each time a new release (dev like official) is done.This would be done by checking merge requests since the last
CHANGELOG.mdchange when the user calls a script to make a new release. User intervention on this changelog will be asked after this (e.g. to "categorize" those change proposal into features, bug fixes and so on).