ReleaseGuidelines updates to reflect OMF process and 12 week dev cycle

[jfh01]

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]

@Retzoh

[thekaveman]

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]

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]

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.

[jfh01]

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

[sarob]

The most recent discussion on this topic in the 27 feb 20 provider wg meeting can be found here.

[thekaveman]

@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.