Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial check in of issue and PR templates #286

Merged
merged 3 commits into from
Apr 9, 2019

Conversation

jfh01
Copy link
Contributor

@jfh01 jfh01 commented Apr 2, 2019

Per discussion on #270, this will help ensure that maintainers have the right information to tag issues and PRs with the correct milestones and labels. The information supplied about breaking/non-breaking changes will also be used to determine which release a given change should be targeted for.

@hunterowens
Copy link
Collaborator

@jfh01 this LGTM, should we merge?

@jfh01
Copy link
Contributor Author

jfh01 commented Apr 5, 2019

I'd like @ccolgrove to review re: language around breaking vs. non-breaking. Also, I want to update CONTRIBUTING and ReleaseGuidelines to reflect this. I'll update the PR later today.

@jfh01
Copy link
Contributor Author

jfh01 commented Apr 9, 2019

@hunterowens I tweaked the language slightly per @ccolgrove's comments and updated ReleaseGuidelines.md to reflect the Milestone tagging process (something we need to apply to this PR!).

Ready to merge.

@hunterowens hunterowens merged commit d399ee7 into openmobilityfoundation:dev Apr 9, 2019
rf- added a commit to remix/mobility-data-specification that referenced this pull request Apr 16, 2019
This commit adds a section to the release guidelines doc clarifying the
distinction between breaking and non-breaking changes, including an
enumeration of what kinds of changes fall in each category. This builds
on language added in openmobilityfoundation#286; I didn't modify those templates here since
their description of breaking vs. non-breaking is still accurate.

I think the most likely area of controversy here is the handling of enum
values. My inclination would actually be to treat changes to enum values
as breaking changes, but it seems like the consensus during the 0.3.1
process so far has been that the benefits of having a lightweight
process for updating enums outweigh the risk of breaking clients that
are doing stricter validations.

Fixes openmobilityfoundation#279
@hunterowens hunterowens added this to the 0.3.1 milestone Apr 18, 2019
@jfh01 jfh01 deleted the dev branch February 20, 2020 17:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants