{"action":"created","issue":{"url":"https://api.github.com/repos/ethereum/solidity/issues/292","labels_url":"https://api.github.com/repos/ethereum/solidity/issues/292/labels{/name}","comments_url":"https://api.github.com/repos/ethereum/solidity/issues/292/comments","events_url":"https://api.github.com/repos/ethereum/solidity/issues/292/events","html_url":"https://github.com/ethereum/solidity/issues/292","id":121433107,"number":292,"title":"Consider semantic versioning semver","user":{"login":"ethers","id":6937903,"avatar_url":"https://avatars.githubusercontent.com/u/6937903?v=3","gravatar_id":"","url":"https://api.github.com/users/ethers","html_url":"https://github.com/ethers","followers_url":"https://api.github.com/users/ethers/followers","following_url":"https://api.github.com/users/ethers/following{/other_user}","gists_url":"https://api.github.com/users/ethers/gists{/gist_id}","starred_url":"https://api.github.com/users/ethers/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ethers/subscriptions","organizations_url":"https://api.github.com/users/ethers/orgs","repos_url":"https://api.github.com/users/ethers/repos","events_url":"https://api.github.com/users/ethers/events{/privacy}","received_events_url":"https://api.github.com/users/ethers/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-12-10T08:59:43Z","updated_at":"2015-12-11T15:25:39Z","closed_at":null,"body":"http://semver.org\r\n\r\nHow do I know when to release 1.0.0?\r\n\r\nIf 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."},"comment":{"url":"https://api.github.com/repos/ethereum/solidity/issues/comments/163963028","html_url":"https://github.com/ethereum/solidity/issues/292#issuecomment-163963028","issue_url":"https://api.github.com/repos/ethereum/solidity/issues/292","id":163963028,"user":{"login":"chriseth","id":9073706,"avatar_url":"https://avatars.githubusercontent.com/u/9073706?v=3","gravatar_id":"","url":"https://api.github.com/users/chriseth","html_url":"https://github.com/chriseth","followers_url":"https://api.github.com/users/chriseth/followers","following_url":"https://api.github.com/users/chriseth/following{/other_user}","gists_url":"https://api.github.com/users/chriseth/gists{/gist_id}","starred_url":"https://api.github.com/users/chriseth/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chriseth/subscriptions","organizations_url":"https://api.github.com/users/chriseth/orgs","repos_url":"https://api.github.com/users/chriseth/repos","events_url":"https://api.github.com/users/chriseth/events{/privacy}","received_events_url":"https://api.github.com/users/chriseth/received_events","type":"User","site_admin":false},"created_at":"2015-12-11T15:25:39Z","updated_at":"2015-12-11T15:25:39Z","body":"I think semantic versioning works probably fine for source-level libraries which have a single entry point (\"API\") and can provide backwards compatibility by having fallbacks that provide the old behaviour. Furthermore, semantic versioning is useful for libraries which are pulled into other projects as a dependency.\r\n\r\nPlease try to prove me wrong, but I think that semantic versioning (in the strict sense) is not applicable to Solidity due to the following reasons:\r\n\r\nSolidity does not have something that can be called \"API\": It has several entry points which may break compatibility: The language itself, the commandline compiler, the C++ library and the javascript compiler. Only the C++ library and the javascript compiler provide a way to avoid breaking changes as I explained above. All others are used by humans directly and thus it is hard to avoid breaking changes without making the language or the commandline compiler cumbersome to use.\r\n\r\nHaving said that, I try to avoid breaking changes in all of the four \"entry points\" listed above. I am a bit less concerned about breaking compatibility in undocumented features, very new features or things considered as bugs. Whenever a breaking change happens, I increment the second version number (not the first as in semantic versioning).\r\n\r\nIf you care about the correctness of you programs, please take a look at the [changelog](https://github.com/ethereum/wiki/wiki/Solidity-Changelog) regularly.\r\n\r\nI would love to hear all your thoughts about versioning, breaking changes and especially experiences with breaking changes concerning Solidity."}}