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

ReleaseGuidelines updates to reflect OMF process and 12 week dev cycle #453

Merged
merged 10 commits into from
Mar 1, 2020

Conversation

jfh01
Copy link
Contributor

@jfh01 jfh01 commented Feb 20, 2020

Explain pull request

This documentation update clarifies the approval process by which the Open Mobility Foundation certifies a release, and updates the release cycle timeline to 12 weeks (from its original 6).

Is this a breaking change

  • No, not breaking

@jfh01 jfh01 added the documentation documentation change can be for code and/or markdown pages label Feb 20, 2020
@jfh01 jfh01 added this to the 0.4.1 milestone Feb 20, 2020
@jfh01 jfh01 requested a review from a team as a code owner February 20, 2020 18:56
@jfh01
Copy link
Contributor Author

jfh01 commented Feb 20, 2020

@Retzoh

@thekaveman
Copy link
Collaborator

I am little curious/concerned with the OMF review process?

  1. The release candidate/WGAD will be provided to the OMF Technology Council for review and comment at least 75 days prior to the desired date of board approval.

  2. The Technology Council will issue a report and/or recommendation for the Board of Directors within 60 days.

  3. The Board of Directors will have a minimum of 30 days to review the Technology Council recommendation before taking a vote on the release candidate/WGAD.

75 days is almost as long as the 12 week cycle itself! Does this mean that after the 12 week cycle we potentially need an additional (75+60+30 = 165) days before making an official release / merging to master?

@jfh01
Copy link
Contributor Author

jfh01 commented Feb 21, 2020

75 days is almost as long as the 12 week cycle itself! Does this mean that after the 12 week cycle we potentially need an additional (75+60+30 = 165) days before making an official release / merging to master?

Yeah, I share this concern as well. The timeline in the bylaws was created in recognition of the infrequency of OMF board meetings, but it creates a pretty significant drag on the cadence of releases.

I need to discuss more with the Board and Technology Council, but my current thinking is that it may be OK to update master to reflect the latest release candidate/WGAD, provided that it is labeled as such and we're clear that it's still under final review.

It's common for standards organizations to release pre-final versions that are stable enough to build to, even if they haven't completed full ratification by the organization. (IEEE, for example)

There's obviously expectation setting we need to do about stability and if/when it's appropriate to write a pre-final spec into law or policy. That's a conversation I need to take up with my governance bodies.

@jfh01
Copy link
Contributor Author

jfh01 commented Feb 27, 2020

Per the 2/27 call, we will:

  1. Add a paragraph that makes clear that cities should not require "release candidate" versions of the spec prior to board approval, but that it's OK for API producers or consumers to start developing to "release candidates" in anticipation of approval.

  2. We will note that the merge to master will happen after board approval.

  3. Will update the wiki to reflect the current approval status and anticipated dates as a release candidate moves through the process.

Copy link
Contributor Author

@jfh01 jfh01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarifying approval process and status of "release candidates" per the 2/27 WG call.

ReleaseGuidelines.md Show resolved Hide resolved
ReleaseGuidelines.md Outdated Show resolved Hide resolved
ReleaseGuidelines.md Outdated Show resolved Hide resolved
ReleaseGuidelines.md Show resolved Hide resolved
@sarob
Copy link
Contributor

sarob commented Feb 27, 2020

thekaveman and others added 5 commits February 27, 2020 12:26
Co-Authored-By: Jascha Franklin-Hodge <[email protected]>
Co-Authored-By: Jascha Franklin-Hodge <[email protected]>
Co-Authored-By: Jascha Franklin-Hodge <[email protected]>
* enumerate steps to create a Release Candidate
* enumerate steps to go from Release Candidate -> Official Release
* new Issue template for Release Candidate Review
* adjust language for out-of-phase hotfixes
@thekaveman
Copy link
Collaborator

@jfh01 I've updated the release steps to include separate phases for the Release Candidate and the Official Release. The goal is to allow publication of the Release Candidate in such a way as work on the next cycle won't be blocked by OMF review, with the understanding that OMF review may elicit further changes to a given Release Candidate.

The only piece that is somewhat fuzzy is how we handle hotfixes (e.g. changes to the 0.3.x line after 0.4.0 has already been released). It's not clear to me if a hotfix would need to follow the same OMF review process, and so the steps I have outlined do not currently take this into consideration.

@thekaveman thekaveman merged commit 3e246c5 into openmobilityfoundation:dev Mar 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation documentation change can be for code and/or markdown pages
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants