Automate the release process

[mjskay]

Quick sanity check. I had proposed a process like this:

• All development happens on / to be merged into the dev branch
• Pull requests / the review process are set up to review code before it ends up on dev.
• When we make a "release", it consists of merging dev onto master and getting endorsements from people.
• The gh-pages branch is auto-updated on commit to track only the master branch.

This separates in-progress version from the "released", community-endorsed version.

However, this has the potential con that the master branch no longer is the development version. It being the first thing you see on Github, maybe we instead want a process like this (basically dev -> master and master -> release from above):

• All development happens on / to be merged into the master branch
• Pull requests / the review process are set up to review code before it ends up on master.
• When we make a "release", it consists of merging master onto the release branch and getting endorsements from people.
• The gh-pages branch is auto-updated on commit to track only the release branch.

?

[mjskay]

Or a third option:

• All development happens on / to be merged into the master branch
• Pull requests / the review process are set up to review code before it ends up on master.
• When we make a "release", it consists of merging master onto the master branch of a (new) guidelines-release repo, which is a fork of guidelines, and getting endorsements from people.
• The gh-pages branch is auto-updated on commit to track the master branch.

This would mean that http://transparentstats.github.io/guidelines would always track the dev version (and we could put a prominent warning at the top of every page indicated this fact and linking to the released version), and http://transparentstats.github.io/guidelines-release would always track the latest released version.

[chatchavan]

I vote for the third option because of the following reasons:

1. Having an instantly-readable development version would potentially allow more contributors to read and check without having jump through all huddles of installing R and stuff. (They can post their input as Github issues).

2. Github pages only allow one .github.io page per repository. Thus, if we wish to have both instantly-readable version of the release and the dev, we will need to place one version of these somewhere anyway.

Addition to the third version:

• Upon release, we should use Github release to make version-tracking happen in one repository.
• Travis can be configured to automatically recompile the release and push to guidelines-release repository.

[mjskay]

• Agreed on using Github release.
• Since travis can auto-push to guidelines-release, maybe it makes sense to keep a release branch in the main repo. The advantage of this is that it makes it easy to make a pull request that will show only the changes since the last release and allow people to comment on it (I can't seem to find a way to get a pull request-type functionality that only uses releases, but if there is such a feature we could use that instead).

I have added a draft of the release process to the wiki: https://github.com/transparentstats/guidelines/wiki/Release-Process

[chatchavan]

The release process sounds good.

Do we need DOI before endorsements? If not, to make life easier, I can create a script on Travis to automate the DOI reservation, addition to RMarkdown, compile, and publish online. The process would looks like:

• ...
• Endorsements updated
• Golden master tag, e.g., GM-v.1.0
• (Travis) reserve DOI
• (Travis) compile and publish book
• (Travis) Zip all source and compiled version
• (Travis) Post the release + tagging on github as v.1.0

I tested Zenodo API, and this process should work.

[mjskay]

Yeah, I don't think we need the DOI before endorsements, so of you can script all that part that would be great!

[chatchavan]

OK. I scheduled time to work on the script and revise the wiki page on 11.01.18.

Until then, @shionguha @steveharoz @dragice, any comments on the process are welcome. Otherwise, I'd assume that you are OK with it.

[dragice]

I agree with the process.

[chatchavan]

I still haven't manage to get it working in a test repository. Will come back to this after my vacation (after 6 Feb.)

• Create Travis to automatically reserve DOI, add to book, compile, publish
• Add author list file to list authors and contributors → add this metadata to Zenodo
• Document the release process