10 ms·

New Versioning Scheme for React

165 points by spicyj 11y ago

sdegutis 11y ago
I am really looking forward to the day we get an industry-wide standardized versioning system. I don't care whether it's semver or not, I don't care if it's 98% perfect and 2% pure evil. I don't care. I just really want to see a universal versioning system. Unfortunately though, I don't think that day will ever come. At least not in my lifetime.
- pc86 11y ago
  > the day we get an industry-wide standardized versioning system Never. A hobby project nobody touches, an internal project at a Fortune 10 company, a huge open source project like WordPress, and a moderately successful SaaS app do not need to have identical versioning systems behind them.
  - tracker1 11y ago
    And depends on the environment and project... if it's a website, then the core release would best be platformNum.releaseNum ... where platform is the underlying platform/architecture, or full rewrite number... Where release number is just incremental... and maybe tying to a git hash or something beyond that.
Hovertruck 11y ago
Surprised they didn't start at 1.0. I understand what they're saying with the reasoning, but I don't think I agree with it. Not that it really matters, I guess.
- spicyj 11y ago
  People already say "React 13" and "React 14" colloquially so we figured calling this one 15.0 would cause the least confusion in the long run.
  - Zarel 11y ago
    Didn't Java do a similar thing, where they renamed Java 1.5 to Java 5?
    - chrisseaton 11y ago
      That used to be a marketing thing and the engineering version was always 1.x, but starting with 9 or 10 can't remember which it's going to be x.0.
      - cpeterso 11y ago
        Sun did the same thing with Solaris, jumping from version 2.6 to 7.
- bryanlarsen 11y ago
  15 sets the right impression. Because it's high, it implies that it's changed 14 times already, and will probably do so again in the future. I've been burned badly before by breaking API changes in patch releases. (Rails 2.4.5). If you're not afraid of bumping the major number on even a minor API change, then it makes it more likely that you will actually do so rather than paying lip service to the idea of semver.
  - azov 11y ago
    Gives the opposite impression to me. If I see a component using semver at version 15.x I'd assume it's very unstable (unless it's very old). So, contrary to what spicyj is saying, to me it seems to create the most confusion in the long run at the expense of addressing some short-term concerns ("people already call it React 14"). I'd much prefer they switched to 1.0.
    - danabramov 11y ago
      You might want to take a look at the blog documenting the releases[1]. Breaking changes happen, but not more often than once in three months. Every breaking change is preceded by a deprecation warning in the previous release, and many changes are automated through codemods. And of course the API surface area is small which is why it’s possible to move fast without breaking things. Don’t forget Facebook has a large React codebase so it cares very much about automating migrations. If React switched to 1.0, with some breaking changes every three months, it would be 14.0 again in a couple of years. Then googling for tutorials would get confusing. Why not do that now? [1]: http://facebook.github.io/react/blog http://facebook.github.io/react/blog
      - lexicality 11y ago
        I would not describe a breaking change every three months as stable. I like the upgrade paths but can you really say with a straight face that an API is stable if the code you write could be invalid a few months later? That's a maintenance nightmare!
mlangenberg 11y ago
Going a great length, just to introduce semver.
- morgante 11y ago
  They were already using semver.
alexatkeplar 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. 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.
sergiotapia 11y ago
So they're going the Google Chrome route, already at v14. Doesn't really matter of course, but it's off-putting. I would have preferred them to use 1.0, clearly indicating it's production ready.
- Cshelton 11y ago
  Right, but they should not be indicating it's ready for production right now...simply because it's been production ready for ~2 years, stable for longer really. We have had React in production for almost 2 years...it has been extremely stable. It should be clear that React is very mature, I think 15.0.0 fits.
- lbenes 11y ago
  No, this has nothing to do with Google's rapid release cycle or versioning scheme. As stated in the article, the API is stable so, it makes sense to switch to a semver scheme.[1] From an engineering perspective, this is a system that makes perfect sense for all libraries to adopt. They choice 15 as the starting MAJOR version because people already referred to 0.14.x as "React 14", avoiding any possible naming confusion. They will remain at 15 as long as there are no major features or API breaking changes introduced. [1] http://semver.org/ http://semver.org/
  - sergiotapia 11y ago
    Thank you[1] [1] Thank you
- bsimpson 11y ago
  > Our business as well as many of yours all depend heavily on the use of React as a core piece of our infrastructure. We're committed to the stability as well as the progress of React going forward. Yeah, it doesn't sound too stable to me either. </sarcasm>
FlailFast 11y ago
0.14 to 15.0 changelog: - Version numbers are now little-endian
- kilovoltaire 11y ago
  It remains big-endian, no?
  - deleted 11y ago
    [deleted]
fuzionmonkey 11y ago
Folks have been using React in production since way before version 0.12, which is when Facebook should have released version 1.0. Releasing 1.0 doesn't in any way limit your ability to make changes in the future. It does, however, allow for more nuanced semantic versioning with the full range of major, minor, and patch versions. This extremely is useful for both library authors and consumers. Better late than never, I suppose, but I just don't understand the pointless sentiment that results in waiting to release a fabled "1.0" release.
bpicolo 11y ago
The biggest issue in upgrading is that all these libraries tend to change their APIs in totally negligible but backwards incompatible ways frequently. Subpar documentation for upgrade paths is plentiful. I wish many of these libs could stick to an api instead of needing every piece of new Javascript hotness every version. =/
- danabramov 11y ago
  I am not sure this is the case with React. If you look through the blog with releases[1], you will find that breaking changes happen not more often than once in three months, that every breaking change is preceded by a deprecation warning in the previous release, and that many changes are automated through codemods. Facebook has a large and growing React codebase, and they use master version of React. Therefore making migrations easy is in its best interests. [1]: http://facebook.github.io/react/blog http://facebook.github.io/react/blog
  - bpicolo 11y ago
    It's more the case for other packages in the ecosystem (especially when combined together) which is part of what this react change aims to help, I realize. E.g. react-router is something I've had trouble with over time, as one example. Getting hot loading set up also gets trickier with each new project (which I'm sure you have experience with ;) Getting react transform running a month ago between all the version incompatibilities was pretty tricky. Following a chain of deprecated projects is not super easy generally.
    - danabramov 11y ago
      I see what you mean but this has no relation to the React release policy. React itself moves with a pace that should be easy to follow. Community projects like React Router move faster but this is not something the React team can help you with. If you don’t want to keep up with the breaking changes there, you can wait for the project to stabilize. For example, you can use Backbone Router which hasn’t changed for years. Finally, if you use something as experimental as hot reloading, please expect it to be tricky to set up until it’s part of official React. This is very experimental territory and there is so much work involved in just making it work that making it stable and easy is not a priority yet.
conradk 11y ago
Everytime I read something about SemVer, breaking changes, etc, I can't help but think about how well Symfony (the PHP framework) handles this. With Symfony, major version changes are not there to break things or bring in tons of new stuff. Instead, it just removes BC layers for stuff that has previously been working but deprecated (with appropriate deprecation warnings). This makes it easy to switch to a new major version: simply fix all deprecated calls and upgrade, done. At least that's what I experienced moving a project from Symfony 2.x to Symfony 3.x.
- squeaky-clean 11y ago
  It sounds like this is exactly what Facebook plans on doing? > Therefore, we're committed to making it easy for most components and libraries built on top of React to be compatible with two major versions at the same time. We will do this by introducing new APIs before completely removing the old ones, thereby avoiding those cliffs. As long as they provide deprecation warnings for APIs that will be removed in the next version, it'll work exactly like you say.
  - danabramov 11y ago
    And, to be clear, this is what React team has been doing all along. When you fixed all deprecation warnings in 0.12, you could update to 0.13. React just moved “0” at the end because it has been used in production for years.
tolmasky 11y ago
This is a great move and hopefully inspires people to take a different look at what versioning is. Right now it serves two masters: marketing and engineering. If everyone just used semver as almost build numbers with meaning, and completely put aside the 'hidden meanings' of 1.x.y or 2.z.w, we'd be in a much better place. The main issue with getting hung up on "what is a 1.0" or "when is this 2.0?" is that even if you finally make sense of it for YOURSELF, everyone outside has such a different interpretation that its meaningless no matter what. However, semver for engineering changes has meaning no matter what. Why hurt your users by introducing a breaking API change in the minor category just because "it doesn't feel like a major change"? I wish we could just rename version to build, have it be semver and be done with it. Then version can be whatever you want and is completely ignored by computers and engineers. Call it version 1.0, version dog, version whatever "feels" right, while we start moving to a world where we can start maker safer decisions.
- treve 11y ago
  The problem with creating two values is that it becomes harder to communicate if you are talking about version x or build x. I wish semver simply moved all digits up one place. The second digit can then mean 'api break', whereas we can easily use the first for marketing purposes.
  - schwabacher 11y ago
    Version could always be words - like ubuntu or android releases: 'Precise Pangolin', 'Ice Cream Sandwich' etc..
    - underwater 11y ago
      I loathe this about Android and OS X. I know that Marshmallow is thr latest and greatest but when I check my phone tells me that it's on 5.0.2. I have no idea what to do with that number. I need to Google the version to see I'm still on Lollipop.
      - 11y ago
davnicwil 11y ago
On Avoiding The Major Cliff: The reasoning for the strategy is sound, but does anyone know the rough cost of leaving in the deprecated apis from the previous version, in terms of additional gzipped file size percentage? Say from 13 to 14 as an example? Further to that, anyone know how effective various dead code elimination tools are at stripping out those unused deprecated apis, for bundled apps that don't have any dependencies requiring anything less than the latest react version?
xjay 11y ago
So.. What's wrong with using datestamps? Use ISO 8601, and add whatever flags you need, and establish some minimum standard vocabulary the AI can search for. :> Development #D: "2016-02-16T15:17:32+00#D#API" Release #R: "2016-02-19T17:37:21+00#R#API" Now anything can look for dates to figure out the age of whatever it is that's running on the system, and maybe even warn about it, disable it, exploit it, etc. (AmigaOS encouraged a $VER: prefix you could scan for, IIRC.) If you still want a custom numbering scheme, just append it to the version string somewhere: "2016-02-19T17:37:21+00#R#API#(1.4.2 Loopy Leopard)" #API could mean there was a change to the API. Review your dependencies. #+API could mean a function was added, but the existing API is stable. (Unless #API was also added separately, in which case a review of the change log is needed.) #-API could mean a function was removed. Review your dependencies. ..or whatever the syntax would be.
- untog 11y ago
  From look at your examples, I'd say what's wrong is that they are very difficult to read. At a very brief glance I didn't notice the change between 16 and 19, and my eyes were drawn to the time, which let's face it, is probably next to useless. And it also doesn't have any of the benefits of semver, like signaling breaking changes.
  - xjay 11y ago
    I'm not sure how to address your first concern (readability), because I don't have the context in which you would need to distinguish one version from another; as opposed to something presenting the versions to you, like a program, website, listing somewhere. The format should be programmatically scanned for, and extracted, and represented in various ways; days ago, hours ago, minutes ago; sorted by newest, oldest; grouped by last three months, etc. > And it also doesn't have any of the benefits of semver, like signaling breaking changes. That's the function of tags. Agree on using #Fix for a corrective release, #Feature for a feature release, and whatever else makes sense. Ideally, there would be a minimum, standard vocabulary that makes sense.
    - rajivm 11y ago
tzs 11y ago
I see many comments on the pros and cons of various version numbering schemes, and I recall many similar discussions going back decades. I have no idea why it has never occurred to me to ask the following question [1]: how is version numbering done in disciplines other than software? Software is young compared to most engineering disciplines. Surely this problem was solved long ago in non-software disciplines and their solutions have been tested by decades, or in some fields even centuries, of practice. [1] idiocy is a plausible theory
rafael-rinaldi 11y ago
I don’t get the _fear_ of releasing the 1st version of a library at `1.0.0` and then doing major bumps whenever needed. That’s why semver exists in the 1st place. There seems to be a lot of FUD around this subject.
Todd 11y ago
I don't know why they didn't just take this opportunity to call it version 1. It seems like the right time. The React Router folks just went through this, with a significant struggle in moving quickly from version 1 to version 2. But it turned out OK. It seems like there's a fear in making the call. Version 1 should be celebrated.
deleted 11y ago
[deleted]

165 points by spicyj 11y ago

I am really looking forward to the day we get an industry-wide standardized versioning system. I don't care whether it's semver or not, I don't care if it's 98% perfect and 2% pure evil. I don't care. I just really want to see a universal versioning system. Unfortunately though, I don't think that day will ever come. At least not in my lifetime.

pc86 11y ago
> the day we get an industry-wide standardized versioning system Never. A hobby project nobody touches, an internal project at a Fortune 10 company, a huge open source project like WordPress, and a moderately successful SaaS app do not need to have identical versioning systems behind them.
- tracker1 11y ago
  And depends on the environment and project... if it's a website, then the core release would best be platformNum.releaseNum ... where platform is the underlying platform/architecture, or full rewrite number... Where release number is just incremental... and maybe tying to a git hash or something beyond that.

Hovertruck 11y ago

Surprised they didn't start at 1.0. I understand what they're saying with the reasoning, but I don't think I agree with it. Not that it really matters, I guess.

spicyj 11y ago
People already say "React 13" and "React 14" colloquially so we figured calling this one 15.0 would cause the least confusion in the long run.
- Zarel 11y ago
  Didn't Java do a similar thing, where they renamed Java 1.5 to Java 5?
  - chrisseaton 11y ago
    That used to be a marketing thing and the engineering version was always 1.x, but starting with 9 or 10 can't remember which it's going to be x.0.
    - cpeterso 11y ago
      Sun did the same thing with Solaris, jumping from version 2.6 to 7.
bryanlarsen 11y ago
15 sets the right impression. Because it's high, it implies that it's changed 14 times already, and will probably do so again in the future. I've been burned badly before by breaking API changes in patch releases. (Rails 2.4.5). If you're not afraid of bumping the major number on even a minor API change, then it makes it more likely that you will actually do so rather than paying lip service to the idea of semver.
- azov 11y ago
  Gives the opposite impression to me. If I see a component using semver at version 15.x I'd assume it's very unstable (unless it's very old). So, contrary to what spicyj is saying, to me it seems to create the most confusion in the long run at the expense of addressing some short-term concerns ("people already call it React 14"). I'd much prefer they switched to 1.0.
  - danabramov 11y ago
    You might want to take a look at the blog documenting the releases[1]. Breaking changes happen, but not more often than once in three months. Every breaking change is preceded by a deprecation warning in the previous release, and many changes are automated through codemods. And of course the API surface area is small which is why it’s possible to move fast without breaking things. Don’t forget Facebook has a large React codebase so it cares very much about automating migrations. If React switched to 1.0, with some breaking changes every three months, it would be 14.0 again in a couple of years. Then googling for tutorials would get confusing. Why not do that now? [1]: http://facebook.github.io/react/blog http://facebook.github.io/react/blog
    - lexicality 11y ago
      I would not describe a breaking change every three months as stable. I like the upgrade paths but can you really say with a straight face that an API is stable if the code you write could be invalid a few months later? That's a maintenance nightmare!

mlangenberg 11y ago

Going a great length, just to introduce semver.

morgante 11y ago
They were already using semver.

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

sergiotapia 11y ago

So they're going the Google Chrome route, already at v14. Doesn't really matter of course, but it's off-putting. I would have preferred them to use 1.0, clearly indicating it's production ready.

Cshelton 11y ago
Right, but they should not be indicating it's ready for production right now...simply because it's been production ready for ~2 years, stable for longer really. We have had React in production for almost 2 years...it has been extremely stable. It should be clear that React is very mature, I think 15.0.0 fits.
lbenes 11y ago
No, this has nothing to do with Google's rapid release cycle or versioning scheme. As stated in the article, the API is stable so, it makes sense to switch to a semver scheme.[1] From an engineering perspective, this is a system that makes perfect sense for all libraries to adopt. They choice 15 as the starting MAJOR version because people already referred to 0.14.x as "React 14", avoiding any possible naming confusion. They will remain at 15 as long as there are no major features or API breaking changes introduced. [1] http://semver.org/ http://semver.org/
- sergiotapia 11y ago
  Thank you[1] [1] Thank you
bsimpson 11y ago
> Our business as well as many of yours all depend heavily on the use of React as a core piece of our infrastructure. We're committed to the stability as well as the progress of React going forward. Yeah, it doesn't sound too stable to me either. </sarcasm>

FlailFast 11y ago

0.14 to 15.0 changelog: - Version numbers are now little-endian

kilovoltaire 11y ago
It remains big-endian, no?
- deleted 11y ago
  [deleted]

fuzionmonkey 11y ago

Folks have been using React in production since way before version 0.12, which is when Facebook should have released version 1.0. Releasing 1.0 doesn't in any way limit your ability to make changes in the future. It does, however, allow for more nuanced semantic versioning with the full range of major, minor, and patch versions. This extremely is useful for both library authors and consumers. Better late than never, I suppose, but I just don't understand the pointless sentiment that results in waiting to release a fabled "1.0" release.

bpicolo 11y ago

The biggest issue in upgrading is that all these libraries tend to change their APIs in totally negligible but backwards incompatible ways frequently. Subpar documentation for upgrade paths is plentiful. I wish many of these libs could stick to an api instead of needing every piece of new Javascript hotness every version. =/

danabramov 11y ago
I am not sure this is the case with React. If you look through the blog with releases[1], you will find that breaking changes happen not more often than once in three months, that every breaking change is preceded by a deprecation warning in the previous release, and that many changes are automated through codemods. Facebook has a large and growing React codebase, and they use master version of React. Therefore making migrations easy is in its best interests. [1]: http://facebook.github.io/react/blog http://facebook.github.io/react/blog
- bpicolo 11y ago
  It's more the case for other packages in the ecosystem (especially when combined together) which is part of what this react change aims to help, I realize. E.g. react-router is something I've had trouble with over time, as one example. Getting hot loading set up also gets trickier with each new project (which I'm sure you have experience with ;) Getting react transform running a month ago between all the version incompatibilities was pretty tricky. Following a chain of deprecated projects is not super easy generally.
  - danabramov 11y ago
    I see what you mean but this has no relation to the React release policy. React itself moves with a pace that should be easy to follow. Community projects like React Router move faster but this is not something the React team can help you with. If you don’t want to keep up with the breaking changes there, you can wait for the project to stabilize. For example, you can use Backbone Router which hasn’t changed for years. Finally, if you use something as experimental as hot reloading, please expect it to be tricky to set up until it’s part of official React. This is very experimental territory and there is so much work involved in just making it work that making it stable and easy is not a priority yet.

conradk 11y ago

Everytime I read something about SemVer, breaking changes, etc, I can't help but think about how well Symfony (the PHP framework) handles this. With Symfony, major version changes are not there to break things or bring in tons of new stuff. Instead, it just removes BC layers for stuff that has previously been working but deprecated (with appropriate deprecation warnings). This makes it easy to switch to a new major version: simply fix all deprecated calls and upgrade, done. At least that's what I experienced moving a project from Symfony 2.x to Symfony 3.x.

squeaky-clean 11y ago
It sounds like this is exactly what Facebook plans on doing? > Therefore, we're committed to making it easy for most components and libraries built on top of React to be compatible with two major versions at the same time. We will do this by introducing new APIs before completely removing the old ones, thereby avoiding those cliffs. As long as they provide deprecation warnings for APIs that will be removed in the next version, it'll work exactly like you say.
- danabramov 11y ago
  And, to be clear, this is what React team has been doing all along. When you fixed all deprecation warnings in 0.12, you could update to 0.13. React just moved “0” at the end because it has been used in production for years.

tolmasky 11y ago

This is a great move and hopefully inspires people to take a different look at what versioning is. Right now it serves two masters: marketing and engineering. If everyone just used semver as almost build numbers with meaning, and completely put aside the 'hidden meanings' of 1.x.y or 2.z.w, we'd be in a much better place. The main issue with getting hung up on "what is a 1.0" or "when is this 2.0?" is that even if you finally make sense of it for YOURSELF, everyone outside has such a different interpretation that its meaningless no matter what. However, semver for engineering changes has meaning no matter what. Why hurt your users by introducing a breaking API change in the minor category just because "it doesn't feel like a major change"? I wish we could just rename version to build, have it be semver and be done with it. Then version can be whatever you want and is completely ignored by computers and engineers. Call it version 1.0, version dog, version whatever "feels" right, while we start moving to a world where we can start maker safer decisions.

treve 11y ago
The problem with creating two values is that it becomes harder to communicate if you are talking about version x or build x. I wish semver simply moved all digits up one place. The second digit can then mean 'api break', whereas we can easily use the first for marketing purposes.
- schwabacher 11y ago
  Version could always be words - like ubuntu or android releases: 'Precise Pangolin', 'Ice Cream Sandwich' etc..
  - underwater 11y ago
    I loathe this about Android and OS X. I know that Marshmallow is thr latest and greatest but when I check my phone tells me that it's on 5.0.2. I have no idea what to do with that number. I need to Google the version to see I'm still on Lollipop.
    - 11y ago

davnicwil 11y ago

On Avoiding The Major Cliff: The reasoning for the strategy is sound, but does anyone know the rough cost of leaving in the deprecated apis from the previous version, in terms of additional gzipped file size percentage? Say from 13 to 14 as an example? Further to that, anyone know how effective various dead code elimination tools are at stripping out those unused deprecated apis, for bundled apps that don't have any dependencies requiring anything less than the latest react version?

xjay 11y ago

So.. What's wrong with using datestamps? Use ISO 8601, and add whatever flags you need, and establish some minimum standard vocabulary the AI can search for. :> Development #D: "2016-02-16T15:17:32+00#D#API" Release #R: "2016-02-19T17:37:21+00#R#API" Now anything can look for dates to figure out the age of whatever it is that's running on the system, and maybe even warn about it, disable it, exploit it, etc. (AmigaOS encouraged a $VER: prefix you could scan for, IIRC.) If you still want a custom numbering scheme, just append it to the version string somewhere: "2016-02-19T17:37:21+00#R#API#(1.4.2 Loopy Leopard)" #API could mean there was a change to the API. Review your dependencies. #+API could mean a function was added, but the existing API is stable. (Unless #API was also added separately, in which case a review of the change log is needed.) #-API could mean a function was removed. Review your dependencies. ..or whatever the syntax would be.

untog 11y ago
From look at your examples, I'd say what's wrong is that they are very difficult to read. At a very brief glance I didn't notice the change between 16 and 19, and my eyes were drawn to the time, which let's face it, is probably next to useless. And it also doesn't have any of the benefits of semver, like signaling breaking changes.
- xjay 11y ago
  I'm not sure how to address your first concern (readability), because I don't have the context in which you would need to distinguish one version from another; as opposed to something presenting the versions to you, like a program, website, listing somewhere. The format should be programmatically scanned for, and extracted, and represented in various ways; days ago, hours ago, minutes ago; sorted by newest, oldest; grouped by last three months, etc. > And it also doesn't have any of the benefits of semver, like signaling breaking changes. That's the function of tags. Agree on using #Fix for a corrective release, #Feature for a feature release, and whatever else makes sense. Ideally, there would be a minimum, standard vocabulary that makes sense.
  - rajivm 11y ago

tzs 11y ago

I see many comments on the pros and cons of various version numbering schemes, and I recall many similar discussions going back decades. I have no idea why it has never occurred to me to ask the following question [1]: how is version numbering done in disciplines other than software? Software is young compared to most engineering disciplines. Surely this problem was solved long ago in non-software disciplines and their solutions have been tested by decades, or in some fields even centuries, of practice. [1] idiocy is a plausible theory

rafael-rinaldi 11y ago

I don’t get the _fear_ of releasing the 1st version of a library at `1.0.0` and then doing major bumps whenever needed. That’s why semver exists in the 1st place. There seems to be a lot of FUD around this subject.

Todd 11y ago

I don't know why they didn't just take this opportunity to call it version 1. It seems like the right time. The React Router folks just went through this, with a significant struggle in moving quickly from version 1 to version 2. But it turned out OK. It seems like there's a fear in making the call. Version 1 should be celebrated.

deleted 11y ago

[deleted]