5 ms·

The fundamental problem with Semver is that the jump from a 0.x.x series to a 1.0.0 is incredibly difficult to call, and often gets delayed almost indefinitely.

The fundamental problem with Semver is that the jump from a 0.x.x series to a 1.0.0 is incredibly difficult to call, and often gets delayed almost indefinitely. 0.9.9 -> 1.0.0 means the opposite of 1.9.9 -> 2.0.0 - the former is an observation of stability ("things are so stable we can leave the 0.x.x series"), the latter is an active statement of a breaking change ("we can't honour the 1.x.x API any longer"). Lots of projects miss the window somewhere around the 0.3.0-0.7.0 versions. We badly need a Semver', which is identical to Semver but starts from 1.0.0 and removes the 0.x.x rule. React is basically retro-fitting Semver' into their project.

fweespeech 11y ago
Honestly I've been leaning towards: [dev || qa || prod].[BreakingChange#].date prod.4.2016.02.19 qa.5.2016.02.19 dev.5.2016.02.19 Useful semantic information is the real series of events, presence of a breaking change, and a statement of relative release stability. This desire to do X.x.x series never made sense to me.
- tracker1 11y ago
  Why is your dev/qa/prod code different? For that matter, you could use a julian date... break.year.julian if, for some reason more than one a day break.year.julian-patch##
  - fweespeech 11y ago
    It's a statement of stability. Dev is frequently the next breaking change and/or code tested solely by is creator. QA is code going through the in-house QA process and is basically a previously nightly build which is trusted enough to be tested against live data. Prod is the last QA promoted to production + any hotfixes. Library changes are slow due to the need to verify we aren't breaking production systems so we frequently have a Prod that doesn't match QA that doesn't match Dev because the process can take a month for breaking changes. Even for non-breaking changes, we generally freeze production for ~1 week if the changes are substantial enough that we might have missed something. We can't exactly ignore production bugs for 1-4 weeks. --- The problem with Julian Dates isn't they aren't immediately human readable which is useful for lining up what was running when.
saidajigumi 11y ago
> We badly need a Semver', which is identical to Semver but starts from 1.0.0 and removes the 0.x.x rule. React is basically retro-fitting Semver' into their project. I can see the desire for this from a code consumer's perspective, I'll argue that this is mostly impossible. New projects often start because there's a new problem (a software architecture, a set of algorithmic tools, etc.) with an inherent learning curve. The 0.x releases reflect the inherent instability of this real-world learning process. Switching to your proposed Semver' model implies that projects must use the compatibility modes (e.g. deprecate-before-removal as this post describes React adopting) of more mature software before their ideas are even partially baked. Many 0.x-era updates (e.g. x++) are near-complete rewrites of the API or sometimes even the entire nascent codebase. I'll hypothesize that a major contributing factor to successful projects gaining wide adoption is the ability go through that vital period of rapid churn.
- alexatkeplar 11y ago
  There's nothing you can do in a 0.x.x release that wouldn't also conform to the Semver rule around incrementing the MAJOR version: http://semver.org/#spec-item-8 http://semver.org/#spec-item-8 The idea of 0.x.x reflecting a level of instability not reflected by MAJOR version bumps is cute in theory but broken in practice.
zodiac 11y ago
> We badly need a Semver', which is identical to Semver but starts from 1.0.0 and removes the 0.x.x rule. React is basically retro-fitting Semver' into their project. Wouldn't that discourage releasing experimental code? I think the very first public release of react was 1.0.0 and they incremented the major version for subsequent incompatible changes, the current major version would be ridiculously high. I know if I did this for experimental code I throw up on github, this would be true.
- krainboltgreene 11y ago
  Experimental code doesn't have to go to a package manager. React-native was handed out via email zip files. Github exists. > the current major version would be ridiculously high So?
  - zodiac 11y ago
    > Experimental code doesn't have to go to a package manager. Just because code is experimental doesn't mean it doesn't need to go in a package manager or, more to the point, doesn't mean it won't benefit from having version numbers.
krainboltgreene 11y ago
It's very clear IMO: http://semver.org/#spec-item-5 http://semver.org/#spec-item-5 http://semver.org/#how-do-i-know-when-to-release-100 http://semver.org/#how-do-i-know-when-to-release-100 But yes, developers are terrible at reading this. Just get rid of 0.X.Y.
- ustolemyname 11y ago
  The answer doesn't match the question. The question is, "How do I know when to release 1.0.0?", whereas the answered question seems to me more, "How do I know if I already should have released 1.0.0?" It's a statement about hindsight, not planning. IE, if I'm wondering if can I make a 1.0.0 release even if I think the project won't have users until, 1.4.x but 1.0.0 represents a logical core, that scenario is not addressed by the "should probably already be 1.0.0" after the fact tests provided.
  - coldtea 11y ago
    >It's a statement about hindsight, not planning. It's about what to do with your code as it is right now -- at every now. >IE, if I'm wondering if can I make a 1.0.0 release even if I think the project won't have users until, 1.4.x but 1.0.0 represents a logical core, that scenario is not addressed by the "should probably already be 1.0.0" after the fact tests provided. I don't think project authors should be worried about making an 1.0.0 in advance, that is, before they have written the code and releases several versions. At which point it comes down to the "hindsight" answer as a heuristic. E.g. "if I'm wondering if can I make a 1.0.0 release even if I think the project won't have users until, 1.4.x" -- there's just no way to knowing whether the project will "have users" until it has.
jrochkind1 11y ago
I think there's absolutely nothing wrong with what React did just now -- they have used the system effectively. (The only problem is that they waited this long to do it). They realized React is _already_ used in production, so it should _already_ be 1.0, and they should be using semver so consumers know when there are breaking changes between versions and when there aren't. They did exactly the right thing. The semver doc already says: > If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0. But it is true that this is frequently ignored by people who otherwise think they're doing semver. I guess _one_ way to deal with that would be to remove "0.x" from semver altogether -- the first version you are allowed to release is 1.0, and it must follow semver rules. But there are plenty of people who don't use semver at all, that would just increase if you removed the availability of pre-1.0 unstable releases. I wish everyone used semver, and I wish everyone who said they were using it actually were using it, and I wish everyone using it followed that part about "If it's being used by tons of people in production and/or you are thinking about backwards compat at all, it should already be 1.0" But what can you do. The semver spec is good already -- I don't agree there's a "fundamental problem" with it in the area you speak of, the problem is people not caring about semver. Changing what's written in the spec won't improve people's behavior in these areas, alas.
- alexatkeplar 11y ago
  The rules for bumping to 1.0.0 are based on hindsight ("probably already be 1.0.0"), exogenous factors ("users") and human emotion ("worrying a lot"). It would be impossible for a computer to correctly bump a piece of software to 1.0.0, and humans mostly get it wrong too.
  - coldtea 11y ago
    Well, it's not as if "1.0.0" is meant to offer any logical and universal guarantees for code quality, completeness, etc. compared to, say, 0.7.x -- apart from what semver asks for. So, as long as it is relatively stable when bumped to 1.0.0, and later releases follow to major/minor rules of semver, it doesn't matter much.
coldtea 11y ago
>The fundamental problem with Semver is that the jump from a 0.x.x series to a 1.0.0 is incredibly difficult to call, and often gets delayed almost indefinitely. That's not a problem with semver. That's a problem with these projects not being stable and being continually changing. If after a period of rapid development a project has been stable, and with no major bugs for months, with only minor changes, they can just as well jump to 1.0.0.
derefr 11y ago
0.x.x makes sense if you explicitly keep a "the ABI is fluid and will break at any time" rule while using it. It basically means that no downstream project can consume a 0.x.x release—which makes sense. 0.x.x is an exploratory phase, and should be passed through as quickly as possible. 1.x.x is then the first "ABI contract": the point at which you can make a call to the project as a library, and know that that call's semantics won't change or break throughout the 1.x.x series. (You could determine something like this mechanically pretty easily... if your platform had anything like "ABI specification files", the way many platforms have "dependency specification files." 1.0.0 would then be the first time you generated an ABI "lock file", that would then be used by your toolchain to fail builds that violate it across the 1.x.x series. To delete-and-regenerate the ABI lockfile would be to bump the major version.) The real problem, though, is that many projects are too big to have a single version sum them up. People need to break components down along stability boundaries—places where rate-of-change changes—and then give versions to those components. NPM libraries are a sort-of-good example of this, though I think there might be better.
- grrowl 11y ago
  This kind of made sense with React as even with this release they were struggling to decide if `context` should be public at all, what shape a "renderable" component should have, etc. Since they've finally decided on these issues with this release, they wouldn't have been able to release it as another v0.x with a straight face.

fweespeech 11y ago

Honestly I've been leaning towards: [dev || qa || prod].[BreakingChange#].date prod.4.2016.02.19 qa.5.2016.02.19 dev.5.2016.02.19 Useful semantic information is the real series of events, presence of a breaking change, and a statement of relative release stability. This desire to do X.x.x series never made sense to me.

tracker1 11y ago
Why is your dev/qa/prod code different? For that matter, you could use a julian date... break.year.julian if, for some reason more than one a day break.year.julian-patch##
- fweespeech 11y ago
  It's a statement of stability. Dev is frequently the next breaking change and/or code tested solely by is creator. QA is code going through the in-house QA process and is basically a previously nightly build which is trusted enough to be tested against live data. Prod is the last QA promoted to production + any hotfixes. Library changes are slow due to the need to verify we aren't breaking production systems so we frequently have a Prod that doesn't match QA that doesn't match Dev because the process can take a month for breaking changes. Even for non-breaking changes, we generally freeze production for ~1 week if the changes are substantial enough that we might have missed something. We can't exactly ignore production bugs for 1-4 weeks. --- The problem with Julian Dates isn't they aren't immediately human readable which is useful for lining up what was running when.

saidajigumi 11y ago

> We badly need a Semver', which is identical to Semver but starts from 1.0.0 and removes the 0.x.x rule. React is basically retro-fitting Semver' into their project. I can see the desire for this from a code consumer's perspective, I'll argue that this is mostly impossible. New projects often start because there's a new problem (a software architecture, a set of algorithmic tools, etc.) with an inherent learning curve. The 0.x releases reflect the inherent instability of this real-world learning process. Switching to your proposed Semver' model implies that projects must use the compatibility modes (e.g. deprecate-before-removal as this post describes React adopting) of more mature software before their ideas are even partially baked. Many 0.x-era updates (e.g. x++) are near-complete rewrites of the API or sometimes even the entire nascent codebase. I'll hypothesize that a major contributing factor to successful projects gaining wide adoption is the ability go through that vital period of rapid churn.

alexatkeplar 11y ago
There's nothing you can do in a 0.x.x release that wouldn't also conform to the Semver rule around incrementing the MAJOR version: http://semver.org/#spec-item-8 http://semver.org/#spec-item-8 The idea of 0.x.x reflecting a level of instability not reflected by MAJOR version bumps is cute in theory but broken in practice.

zodiac 11y ago

> We badly need a Semver', which is identical to Semver but starts from 1.0.0 and removes the 0.x.x rule. React is basically retro-fitting Semver' into their project. Wouldn't that discourage releasing experimental code? I think the very first public release of react was 1.0.0 and they incremented the major version for subsequent incompatible changes, the current major version would be ridiculously high. I know if I did this for experimental code I throw up on github, this would be true.

krainboltgreene 11y ago
Experimental code doesn't have to go to a package manager. React-native was handed out via email zip files. Github exists. > the current major version would be ridiculously high So?
- zodiac 11y ago
  > Experimental code doesn't have to go to a package manager. Just because code is experimental doesn't mean it doesn't need to go in a package manager or, more to the point, doesn't mean it won't benefit from having version numbers.

krainboltgreene 11y ago

It's very clear IMO: http://semver.org/#spec-item-5 http://semver.org/#spec-item-5 http://semver.org/#how-do-i-know-when-to-release-100 http://semver.org/#how-do-i-know-when-to-release-100 But yes, developers are terrible at reading this. Just get rid of 0.X.Y.

ustolemyname 11y ago
The answer doesn't match the question. The question is, "How do I know when to release 1.0.0?", whereas the answered question seems to me more, "How do I know if I already should have released 1.0.0?" It's a statement about hindsight, not planning. IE, if I'm wondering if can I make a 1.0.0 release even if I think the project won't have users until, 1.4.x but 1.0.0 represents a logical core, that scenario is not addressed by the "should probably already be 1.0.0" after the fact tests provided.
- coldtea 11y ago
  >It's a statement about hindsight, not planning. It's about what to do with your code as it is right now -- at every now. >IE, if I'm wondering if can I make a 1.0.0 release even if I think the project won't have users until, 1.4.x but 1.0.0 represents a logical core, that scenario is not addressed by the "should probably already be 1.0.0" after the fact tests provided. I don't think project authors should be worried about making an 1.0.0 in advance, that is, before they have written the code and releases several versions. At which point it comes down to the "hindsight" answer as a heuristic. E.g. "if I'm wondering if can I make a 1.0.0 release even if I think the project won't have users until, 1.4.x" -- there's just no way to knowing whether the project will "have users" until it has.

jrochkind1 11y ago

I think there's absolutely nothing wrong with what React did just now -- they have used the system effectively. (The only problem is that they waited this long to do it). They realized React is _already_ used in production, so it should _already_ be 1.0, and they should be using semver so consumers know when there are breaking changes between versions and when there aren't. They did exactly the right thing. The semver doc already says: > If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0. But it is true that this is frequently ignored by people who otherwise think they're doing semver. I guess _one_ way to deal with that would be to remove "0.x" from semver altogether -- the first version you are allowed to release is 1.0, and it must follow semver rules. But there are plenty of people who don't use semver at all, that would just increase if you removed the availability of pre-1.0 unstable releases. I wish everyone used semver, and I wish everyone who said they were using it actually were using it, and I wish everyone using it followed that part about "If it's being used by tons of people in production and/or you are thinking about backwards compat at all, it should already be 1.0" But what can you do. The semver spec is good already -- I don't agree there's a "fundamental problem" with it in the area you speak of, the problem is people not caring about semver. Changing what's written in the spec won't improve people's behavior in these areas, alas.

alexatkeplar 11y ago
The rules for bumping to 1.0.0 are based on hindsight ("probably already be 1.0.0"), exogenous factors ("users") and human emotion ("worrying a lot"). It would be impossible for a computer to correctly bump a piece of software to 1.0.0, and humans mostly get it wrong too.
- coldtea 11y ago
  Well, it's not as if "1.0.0" is meant to offer any logical and universal guarantees for code quality, completeness, etc. compared to, say, 0.7.x -- apart from what semver asks for. So, as long as it is relatively stable when bumped to 1.0.0, and later releases follow to major/minor rules of semver, it doesn't matter much.

coldtea 11y ago

>The fundamental problem with Semver is that the jump from a 0.x.x series to a 1.0.0 is incredibly difficult to call, and often gets delayed almost indefinitely. That's not a problem with semver. That's a problem with these projects not being stable and being continually changing. If after a period of rapid development a project has been stable, and with no major bugs for months, with only minor changes, they can just as well jump to 1.0.0.

derefr 11y ago

0.x.x makes sense if you explicitly keep a "the ABI is fluid and will break at any time" rule while using it. It basically means that no downstream project can consume a 0.x.x release—which makes sense. 0.x.x is an exploratory phase, and should be passed through as quickly as possible. 1.x.x is then the first "ABI contract": the point at which you can make a call to the project as a library, and know that that call's semantics won't change or break throughout the 1.x.x series. (You could determine something like this mechanically pretty easily... if your platform had anything like "ABI specification files", the way many platforms have "dependency specification files." 1.0.0 would then be the first time you generated an ABI "lock file", that would then be used by your toolchain to fail builds that violate it across the 1.x.x series. To delete-and-regenerate the ABI lockfile would be to bump the major version.) The real problem, though, is that many projects are too big to have a single version sum them up. People need to break components down along stability boundaries—places where rate-of-change changes—and then give versions to those components. NPM libraries are a sort-of-good example of this, though I think there might be better.

grrowl 11y ago
This kind of made sense with React as even with this release they were struggling to decide if `context` should be public at all, what shape a "renderable" component should have, etc. Since they've finally decided on these issues with this release, they wouldn't have been able to release it as another v0.x with a straight face.