Development & release best-practice / guidelines

[joncison]

Let's enumerate things here (ideally in sensible order)

Release process

• pre-announce changes to “stable” (especially breaking API changes)
• independent verification of issues “staged for release” before deploying to “stable” (by at least 2 members of registry-core?)
• requirement of formal testing of about-to-be-deployed dev system
• merge changes from “dev” and “hotfixes” into “stable” (and tagging with a release number)
• requirement of testing of newly deployed "stable" deployment
• update the changelog
• update GitHub issue tracker (labelling, closing, replying etc.)
• announce the new stable deployment
• what is the deployment frequency; quarterly? ad-hoc?
• clarify practical meaning / application of the GitHub issue labels, e.g. all issues fixed in “dev” should be “staged for release” but not closed until independently verified etc.
• etc.

Best practice

• discussion needed before implementing major features
• always work in a "temporary" ("feature" or "bugfix") branch, although trivial changes are ok to make directly in dev branch?
• what should / shouldn’t happen at release time, e.g. no commits / pull requests to “dev” during set deployment period
• etc. etc.

Agreement of new features by some some clear GitHub-based mechanism, e.g.

• PRs to “dev” need a +1 (from registry-core) to get merged
• PRs to “dev” that get a -1 (from registry-core) do not go in (veto)
• for changes to subsequently be merged into “stable”, a +1 from at least two people (from core-dev) is needed

cc @hansioan @piotrgithub1 @hmenager @bgruening FYI ... made some nice progress on https://github.com/bio-tools/biotoolsRegistry/blob/master/contribution.md, but good to work on above in FR next week