Release process and contribution guidelines #264
Conversation
Bring fork up-to-date with CityOfLosAngeles repo
Updated to reflect that the process applies only to provider for now.
Clarified language around release notes and change descriptions.
ReleaseGuidelines.md
Outdated
| @@ -19,7 +23,7 @@ Given that MDS is stabilizing under MAJOR version `0.x` right now, it should be | |||
|
|
|||
| At this early stage, MDS will be moving relatively quickly with an eye toward stabilization rather than backwards-compatibility. | |||
|
|
|||
| For now, MDS will maintain *two concurrent (MINOR) versions* (e.g. if `0.3.0` were the current verison, the `0.2.x` series would continue to receive maintenace in addition to `0.3.x`). | |||
| For now, MDS will maintain *two concurrent (MINOR) versions* (e.g. if `0.3.0` were the current version, the `0.2.x` series would continue to receive maintenance in addition to `0.3.x`). | |||
|
|
|||
| ## Branch Mechanics | |||
There was a problem hiding this comment.
@jfh01 can you add some language about how to merge breaking requests (ie, stuff that is staged for a 0.x.0 release) versus stuff that is non-breaking (ie, stuff staged for a 0.3.x) release. I don't wanna end up having to do all breaking changes in a 6 week cycle.
There was a problem hiding this comment.
@hunterowens how about this:
Breaking changes should always be merged to develop. These may be merged at any time and will be incorporated into the next minor release. For non-breaking changes, these should either be merged to develop if the next release is a minor release, or to the appropriate release branch if the next version is a patch release.
There was a problem hiding this comment.
Looks good.
Would add at the end
"During each cycle, we merge changes to both dev and 0.n.x branches, so breaking changes can be proposed and worked on at any time"
There was a problem hiding this comment.
Additional changes to reflect comments from @hunterowens, @ccolgrove, and @toddapetersen.
There was a problem hiding this comment.
In ReleaseGuidelines.md, what does everyone think about swapping the Branch Mechanics and Release Process sections?
Release Process seems like the most important piece and sets out the philosophy, whereas Branch Mechanics is more in the weeds like the Checklist at the end.
|
@hunterowens I think this should have been targeted at |
|
@thekaveman since I merged In other news, let's make sure to take a look at all existing PRs as part of the release cycle next week and make sure they are targeting the correct branch. |
Definition of a more structured release process and an initial set of contribution guidelines to address #262 and #176.