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

versioning scheme #3

Open
juliangruber opened this issue Dec 2, 2019 · 5 comments
Open

versioning scheme #3

juliangruber opened this issue Dec 2, 2019 · 5 comments
Labels

Comments

@juliangruber
Copy link
Member

@juliangruber juliangruber commented Dec 2, 2019

Given the psychological value of having full versions for people’s perception of stability (and not sticking in beta for forever), we follow this product versioning scheme that has multiple major version changes over the course of the first developments.

If you're referring to the semver spec, any change between 0.0.0 and 1.0.0 can be a breaking change but doesn't have to.

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Is "major version change" referring to semver, or did you mean something different?

@chartgerink

This comment has been minimized.

Copy link
Contributor

@chartgerink chartgerink commented Dec 2, 2019

Ah that took me a few minutes to parse. I thought I wrote that second quote and got confused 🤸‍♀

I'm not referring to the semver definition, I'm talking about how we map our roadmap on it, to create the psychological sense of progress. That means that v1.0.0 is not at all the complete product, but one that is very workable. v2.0.0 then gets released when we've added the versions in minor releases of v1.0.0 that collectively "unlock" to go to v2.0.0.

It gives people more confidence if we're at v5.0.0 for example, than map the same functionality onto a roadmap that aims for that to be called v1.0.0.

Does that make sense? I hate it when software I want to use is stuck in v0.9.11 or is called beta for three years in a row, because it delegitimises its value.

@juliangruber

This comment has been minimized.

Copy link
Member Author

@juliangruber juliangruber commented Dec 2, 2019

That totally makes sense, I frequently use software of version 10 or higher. Version 1 is the first usable version, and any breaking change makes it a new major version. That's how you commonly do it with semver at least.

@chartgerink

This comment has been minimized.

Copy link
Contributor

@chartgerink chartgerink commented Dec 9, 2019

We had a few discussions on Slack about this further and I'd like to document the outcome.

We'll be using the non-semver versioning scheme until we implement our feature requirements and get everything stable enough. Subsequently we bump to v1.0.0 (regardless of the preceding version number), after which we'll fully work within the semver scheme.

Does that sound okay to you, @juliangruber?

@juliangruber

This comment has been minimized.

Copy link
Member Author

@juliangruber juliangruber commented Dec 11, 2019

as mentioned somewhere else (can't remember where) the chaotic pre-1.x phase is actually part of semver so we're still following it :)

@chartgerink

This comment has been minimized.

Copy link
Contributor

@chartgerink chartgerink commented Dec 11, 2019

Hihi yes that discussion followed this one. I adjusted it a bit and think this covers it?

We'll be using the semver versioning scheme and operate in the v0.x.x space until we implement our feature requirements and get everything stable enough. Subsequently we bump to v1.0.0 (regardless of the preceding version number), regardless of where we are (e.g., v0.6.4 might be bumped to v1.0.0).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.