Feature/release scripts#14
Conversation
Steven-Eardley
left a comment
Steven-Eardley
left a comment
There was a problem hiding this comment.
I think out of these, the static pages one is what I'd be most likely to use. I do have concerns about the edge cases you'll encounter when doing pulls and pushes so I worry about them being done in a script, in case they require user input.
There's also a lot of code duplication involved across these scripts - the steps could be factored out to shared functions and called from the individual scripts. That might make it look a lot more complicated, however.
A couple of comments added, but the only change it needs is to be less opinionated about when a version bump occurs. JS changes isn't the only time.
| fi | ||
|
|
||
| if confirm "git pull (develop)"; then | ||
| git pull |
There was a problem hiding this comment.
This might only work if there are only fast-forward merges (i.e. non-interactive) on pull.
|
|
||
| # Create release branch | ||
| if confirm "git flow release start $RELEASE_NAME"; then | ||
| git flow release start $RELEASE_NAME |
There was a problem hiding this comment.
Worth documenting that git flow (and git flow setup / config) are dependencies.
| echo "You need to update the version in setup.py and portality/settings.py" | ||
|
|
||
| if confirm "Edit setup.py to update DOAJ_VERSION"; then | ||
| ${EDITOR:-vi} setup.py |
There was a problem hiding this comment.
I presume this is the environment variable to use to get the user's default editor?
| git commit -m "Update DOAJ_VERSION for release" | ||
| fi | ||
| else | ||
| echo "No JS/CSS changes detected. Version update not required." |
There was a problem hiding this comment.
We also update the version for other reasons e.g. for the changelog, and for model changes. Apart from static pages, I don't do many releases without bumping the version. It also serves to tell the servers that the package is updated.
2 participants
These scripts are useful to make releases