[Release Process] Major vs. Minor (vs. Patch) releases

[RobDolinMS]

The OCI Release Process should differentiate between major and minor releases.

Possibly longer waiting period and higher threshold for consensus for major (vs. minor)

/cc @philips

[wking]

On Fri, Jun 10, 2016 at 06:18:56AM -0700, Rob Dolin (MSFT) wrote:

The OCI Release Process should differentiate between major and minor
releases.

I'm less sure about this, although it depends on which spec-consumer
the SemVer is aimed at (runtime maintainers or config authors /
runtime callers) 1.

[wking]

And while I think these sub-issues around ideas from #15 are a great
idea for focusing discussion, we should probably make new ones in the
project-template repository [1,2,3,4]. It's possible that
@diogomonica remains unconvinced since his only comments suggest TOB
jurisdiction [5,6], but as I understand it his main reasoning is “this
is an opencontainers/tob PR” 6.

[RobDolinMS]

@wking A major release has intellectual property implications for OCI member companies [1]. It would be good to have differentiated bars for a minor release (which might be done on a date-driven cadence) and a major release.

[1] Section 8.d. of https://www.opencontainers.org/about/governance

[wking]

On Fri, Jun 10, 2016 at 08:42:46AM -0700, Rob Dolin (MSFT) wrote:

A major release has intellectual property implications for OCI
member companies 1…

1 Section 8.d. of https://www.opencontainers.org/about/governance

I don't see any major/minor wording in that (it's just “finalization
and release of a new version”) or [1] (which just has a field for the
spec/version being covered. If the intention is to make a major/minor
distinction in terms of obligations, that should probably go in as a
charter change.

[philips]

@RobDolinMS Both you and Stephen have raised the concern that the current proposal is insufficient: 3 week minimum with weeks added automatically when changes are made. Can you tell me what you feel the right minimum to set is and why for each of these processes?

I proposed the setup because I assumed at least some level of conversation would happen during the process and the three week minimum was very unlikely to happen in practice. But, in the optimistic case where all of the stake holders know what is happening because of the better release communication to dev@ that there would be an acceptable "happy path" that would cause some level of urgency to ensure people pay attention. Maybe 4 weeks would be more reasonable? Three RCs a minimum of 1 week apart?

So, maybe you can talk through your thought process? I would be happy to add some time, I want to try to get to some consensus and have some reasoning behind it.

[philips]

@RobDolinMS What I would like to encourage is early communication and regular forward progress. What I want to avoid is everyone chiming in only on the final RC because this is the "one that counts".

[philips]

@RobDolinMS tried to add some motivation around the process to help explain: 1e3b643

[wking]

On Fri, Jun 10, 2016 at 09:31:40AM -0700, W. Trevor King wrote:

On Fri, Jun 10, 2016 at 08:42:46AM -0700, Rob Dolin (MSFT) wrote:

A major release has intellectual property implications for OCI
member companies 1…

1 Section 8.d. of https://www.opencontainers.org/about/governance

I don't see any major/minor wording in that…

Ah, the major/minor distinction is in §8.e:

Each new version of the specification will be designated by a change
in the number to the left of the decimal point (x in an x.y format
where y designates interim update releases).

That's not SemVer, where a minor release marks the addition of a new,
backwards-compatible feature 1. And “new feature” seems like the
trigger for patent concerns, not “backwards-incompatible change”. So
I still think we need a charter update to get OFWa patent grants for
major and minor bumps (but probably not bugfix bumps). But my earlier
“I don't see a major/minor distinction in the charter” was incorrect.