open-feature / spec

OpenFeature specification
https://openfeature.dev
Apache License 2.0
612 stars 35 forks source link

[Proposal] Spec Versioning #109

Closed beeme1mr closed 1 year ago

beeme1mr commented 2 years ago

Problem

The spec in its current form is not versioned. There's a concept of experimental and alpha statuses but it's impossible to say an SDK is spec compliant because the spec is a moving target.

Solution

Adopt semantic versioning, use git tags, and perform a GitHub release. Since we're in an alpha state, it's important that the major version is 0, which means anything MAY change. While breaking changes are still possible, they should be clearly communicated and documented.

SDKs do not need to match the spec version they conform to. However, the SDKs should clearly state what version of the spec they're compliant with.

Questions

justinabrahms commented 2 years ago

I would prefer that we have alpha as 0.1.x and beta as 0.2.x.

I don't think we should automate the versioning. 0.x.x have no guarantees of backwards compatibility, which is correct for the spec in this state.

When we hit our "beta" milestone, we should cut 0.2.0 and then begin work on 0.3.x.

toddbaert commented 2 years ago

I'm OK without automated versioning, but I think it would be good to have automated changelog generation based on commit messages, which we could use to do our own manual versioning with more confidence.

beeme1mr commented 1 year ago

Version v0.1.0 has been released! :partying_face: