search

codemeta / codemeta.github.io

CodeMeta web site
https://codemeta.github.io
1 stars 18 forks source link

switch to GitFlow model for development #32

Open mbjones opened 4 years ago

mbjones commented 4 years ago

The current master branch was used for both development and releases in prior work on CodeMeta. I propose that we have an urgent need to use a GitFlow style process so that changes targeting the next release are done on a develop branch, which is then only merged to master upon release. This would allow the current master view on GitHub to always reflect the current stable release, but let work on the next version continue on develop.

I propose that we follow a system like the one we developed for science on schema.org. Feedback appreciated... cc: @cboettig @amoeba

We might even consider merging CodeMeta into Science on Schema.org given that they have a mature community working towards similar goals on the Dataset side of schema.org. Feedback @cboettig @ashepherd ?

amoeba commented 4 years ago

I propose that we follow a system like the one we developed for science on schema.org . Feedback appreciated... cc: @cboettig @amoeba

Fine by me if others are fine with it. I'm more of a contributor here and I am able to contribute fine either way.

ashepherd commented 4 years ago

sounds good to me! Would be great to have CodeMeta as part of Science on Schema.org! @mbjones we can add this to the agenda for the next ESIP schema.org cluster meeting on Monday 4/6

mbjones commented 4 years ago

@ashepherd I can't make the 4/6 meeting due to a conflict, but feel free to discuss it without me. If we do decide such a thing, @cboettig and others from the CodeMeta task force should be asked for input.

ashepherd commented 4 years ago

ok, let's wait until Carl can chime in before introducing the idea to the cluster.

cboettig commented 4 years ago

Quick point of clarification: are we referring to GitFlow just for the this repo (website) or the main codemeta/codemeta page, or both?

I'm happy with GitFlow, though I think we should make develop the default branch then. In my limited experience, most contributors we see on GtiHub are more familiar with a GitHubFlow model and tend to send PRs against the default branch. In general I am not entirely sure what we gain from GitFlow vs GitHubFlow -- in particular, I would prefer that things that need to refer to a 'latest stable release' rely on the GitHub releases / git tags model, rather than the assumption that "master is always the latest release", as the latter creates a more slippery definition of a "release" that is harder to refer to later on.

In any event, I do agree we could use more hygiene in our process.

I also think we need to implement an automated deployment model for the website, e.g. using GitHub Actions for blogdown sites, ideally using a single-branch setup for hosting both source and then the built static site in 'docs' rather than the current older convention of using a separate branch.