{"id":15919844,"url":"https://github.com/jaredly/ferver","last_synced_at":"2026-01-03T18:40:45.753Z","repository":{"id":19639027,"uuid":"22891144","full_name":"jaredly/ferver","owner":"jaredly","description":"fe(a)rver - versioning for those of us who only care about breaking changes","archived":false,"fork":false,"pushed_at":"2014-08-12T20:20:12.000Z","size":117,"stargazers_count":6,"open_issues_count":0,"forks_count":5,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-02-19T13:11:57.152Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jaredly.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2014-08-12T20:19:36.000Z","updated_at":"2025-02-18T13:55:14.000Z","dependencies_parsed_at":"2022-08-24T02:50:21.198Z","dependency_job_id":null,"html_url":"https://github.com/jaredly/ferver","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jaredly%2Fferver","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jaredly%2Fferver/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jaredly%2Fferver/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jaredly%2Fferver/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jaredly","download_url":"https://codeload.github.com/jaredly/ferver/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":244656682,"owners_count":20488638,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-06T19:05:08.905Z","updated_at":"2026-01-03T18:40:45.725Z","avatar_url":"https://github.com/jaredly.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"\n# Fear-Driven Versioning\n\nFe(a)rVer - a versioning scheme for those of us who only care about breaking changes.\nThis is similar to [semver](http://semver.org) and uses the same operators like\n`~` and `^`, but has slightly different as well as stricter semantics.\n\nThe primary differences are:\n\n- No `patch` version bumps are allowed for any changes that\n  have a possibility of being a breaking change.\n- \"minor\" breaking changes are allowed in `minor` version bumps.\n\nLarge projects like `jQuery` effectively use this type of versioning\nas introducing breaking changes only in `major` versions\nwould mean very high version numbers like Chrome and Firefox.\nBreaking changes are inevitable in software development,\nand we shouldn't make it any more difficult on ourselves.\nFerver is more practical and is more inline with our common sense.\n\nThe primary purpose of this versioning scheme is to allow\nconsumers of libraries to use `~x.y.z` versioning\nwithout worrying about breaking changes as well as receiving updates.\nSemver's definition of a `patch` is simply too vague and idealistic.\n\n## Semantics\n\n### x.y.z\n\nLike semver, ferver uses the same 3-number versioning scheme:\n\n```\n\u003cmajor\u003e.\u003cminor\u003e.\u003cpatch\u003e\n```\n\nHowever, the semantics for each number is different:\n\n| Number        | semver                  | ferver                  |\n|---------------|-------------------------|-------------------------|\n| Major         | Breaking changes        | Major breaking changes  |\n| Minor         | New features            | Minor breaking changes  |\n| Patch         | Non-breaking bug fixes  | Non-breaking changes    |\n\nThus, for ferver, `patch` isn't really a \"patch\", just a \"change\",\nbut we'll continue calling it `patch` because I can't think of a better word.\n\n### 0.y.z.\n\n`0.y.z` versions are development versions.\nConsumers __should not__ use libraries with only `0.y.z` versions published.\nAuthors __should__ release a `1.0.0` version as soon as possible to\ndeclare a \"stable\" library.\n\nThe semantics for `0.y.z` versions are very similar to `x.y.z` semantics.\nUnlike semver, there are defined semantics for versions `\u003c 1.0.0`.\n\n| Number        | semver                  | ferver                  |\n|---------------|-------------------------|-------------------------|\n| Major         | 0                       | 0                       |\n| Minor         | Undefined               | Breaking Changes        |\n| Patch         | Undefined               | Non-breaking changes    |\n\nThus, bump `minor` only if you introduce a breaking change in development\n(no matter how major or minor), and bump `patch` otherwise.\n\n### Affixes\n\nFerver does not allow affixes. There's no `1.0.0-beta1` or `2.0.0-1`.\nIn other words, only \"strict\" versions are allowed.\nDevelopment versions should be published in a different channel.\n\n## Consuming ferver packages\n\nConsumers of packages using fear-driven versioning __should not__ use `^x.y.z`\nversion ranges and instead __should__ use `~x.y.z`, whether or not `x \u003e 0`.\n\n## Types of Changes\n\n### Major breaking changes\n\nMajor breaking changes are changes which fundamentally change the library.\n\n- You've broken a \"majority\" or the \"primary\" API.\n- You're combining many \"minor\" breaking changes.\n- You've completely removed some features.\n- You've decided to change the character, purpose, or philosophy of the library.\n- You've significantly refactored the library.\n\nDevelopers __should__ bump the major version on any breaking changes,\nbut __may__ instead opt for bumping the `minor` version if appropriate.\n\nWhen you're not sure whether a breaking change is minor or major,\nit's a major breaking change.\n\n### Minor breaking changes\n\nMinor breaking changes are relatively minor breaking changes in the library\nor changes that __may__ introduce a breaking change.\n\n- You've changed how one of many APIs works.\n- You've deprecated any feature.\n- You've fixed a bug that people could have been using as a feature.\n- You've refactored a non-trivial portion of your code.\n- You've updated an external dependency that may introduce some breaking changes.\n- You've changed one of your dependencies.\n\nMinor versions should be bumped __liberally__.\nIf there's a `\u003e 0%` change a change will break someone's app,\nyou __must__ bump the minor version, even if it's a \"patch\" according to semver.\n\n### Non-breaking changes\n\nNon-breaking changes are changes that have __absolutely no chance of breaking anything__.\nWhen in doubt, bump a minor version.\n\n- Adding a completely new feature.\n- Fixing an obvious bug that no body could have relied on.\n- Documentation updates.\n- Updating package metadata.\n\n## Semver Compatibility\n\nPeople may not expect this type of versioning scheme,\nso here are a few ways to improve semver compatibility.\n\n### Bump `minor` on new features\n\nWith ferver, new features shouldn't bump `minor`, only `patch`.\nThis is more ideal as people who use `~x.y.z` will then be able to receive the\nnew feature. But this isn't really important since if the consumer needed\nthis new feature in the first place, s/he wouldn't have used your library.\n\nHowever, you're free to bump `minor` when you release a new feature\nsince versioning isn't just about what has changed, but marketing as well.\nAs long as you don't introducing any breaking changes on `patch`, you're good.\n\n### Bump `major` instead of `minor` whenever possible\n\nTry to use the semver logic of `major === breaking changes`.\nThis is impossible with larger projects like `jQuery` because\nbreaking changes happen all the time to one of their many APIs.\nBut if you have a very small library with very few APIs,\nit's easier to just bump `major` and not confuse any people.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjaredly%2Fferver","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjaredly%2Fferver","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjaredly%2Fferver/lists"}