)]}'
{
  "commit": "ed7ebdc7f7fa748f89372e034d6d983835db5d42",
  "tree": "5fcaab8fd8132ada83de8326af91cbf4a75a42cc",
  "parents": [
    "b583c3ab6855d491154f7be6d3bdb5c44380290c"
  ],
  "author": {
    "name": "Laslo Hunhold",
    "email": "dev@frign.de",
    "time": "Wed Oct 05 22:14:17 2022 +0200"
  },
  "committer": {
    "name": "Laslo Hunhold",
    "email": "dev@frign.de",
    "time": "Wed Oct 05 22:44:52 2022 +0200"
  },
  "message": "Switch to semantic versioning and improve dynamic library handling\n\nAfter long consideration, I\u0027ve made the decision to switch this project\nover to semantic versioning[0]. While it made sense for farbfeld in\nsome way to use incremental versioning, for libraries it is almost\ncanonical to make use of semantic versioning instead.\n\nGiven there have been breaking API-changes since version 1 (which now\ncorresponds to 1.0.0), the major version will naturally be bumped.\nAfterwards though, additions to the API will only trigger a minor bump,\nas is convention, while also making it possible to release\npatch-releases when there have been errors. Because, to be frank, if you\nonly have full integers, you kind of get anxiety that a release is in\nfact correct, given you don\u0027t want to waste another whole integer-step\non a simple bugfix.\n\nFor farbfeld, which is very small and self-contained, it was okay, but\nlibgrapheme has become complex enough to warrant this.\n\nRegarding dynamic library handling: I really read a lot about it and\nreferred to some interesting articles like [1] to figure out what the\nbest approach is to reflect versioning in the dynamic library.\n\nDoing this portably is quite difficult and the common approach to\nsimply use the major version has some serious drawbacks, given a\nbinary linked against the version 2.4 can falsely be linked against\nversions 2.3.x, 2.2.x, 2.1.x or 2.0.x at runtime, even though they\nlack functions added in 2.4 that might be used in the binary, something\nexplicitly allowed in semantic versioning.\n\nA portable trick described in [1] is to set SONAME to contain\nMAJOR.MINOR and explicitly create symlinks from all \"lower\" MAJOR-MINOR-\ncombinations with the same MAJOR-version to ensure forward-compatibility\nfor all binaries linked against a certain MAJOR.MINOR-combination.\n\nThis way, a library linked against libgrapheme-2.4 is properly linkable\nagainst libgrapheme-2.5 at runtime (given semantic versioning ensures\nforward compatibility), but at the same time, it will not allow linking\nagainst libgrapheme-2.2 (if that is installed), given it has no\nexplicit symlink set from libgrapheme-2.2 at libgrapheme.2.5.\n\n[0]:https://semver.org/\n[1]:https://begriffs.com/posts/2021-07-04-shared-libraries.html\n\nSigned-off-by: Laslo Hunhold \u003cdev@frign.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "d325c1b6a3af50c9b80bab876f5f7b8865962f84",
      "old_mode": 33188,
      "old_path": "Makefile",
      "new_id": "1f9edc729b2ffd95d5c9e91e2371d2227ff0195c",
      "new_mode": 33188,
      "new_path": "Makefile"
    },
    {
      "type": "modify",
      "old_id": "14aedd3ad3cb9a33dc2232fe99bb54b67818b7cc",
      "old_mode": 33188,
      "old_path": "config.mk",
      "new_id": "f8bd40fb411b880456d0f683b429965e4cf43250",
      "new_mode": 33188,
      "new_path": "config.mk"
    }
  ]
}