Open mjskay opened 6 years ago
Or a third option:
master
branchmaster
.master
onto the master
branch of a (new) guidelines-release
repo, which is a fork of guidelines
, and getting endorsements from people.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.
I vote for the third option because of the following reasons:
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).
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:
guidelines-release
repository.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
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:
GM-v.1.0
v.1.0
I tested Zenodo API, and this process should work.
Yeah, I don't think we need the DOI before endorsements, so of you can script all that part that would be great!
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.
I agree with the process.
I still haven't manage to get it working in a test repository. Will come back to this after my vacation (after 6 Feb.)
Quick sanity check. I had proposed a process like this:
dev
branchdev
.dev
ontomaster
and getting endorsements from people.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 (basicallydev
->master
andmaster
->release
from above):master
branchmaster
.master
onto therelease
branch and getting endorsements from people.release
branch.?