{"action":"created","issue":{"url":"https://api.github.com/repos/mojombo/semver/issues/200","labels_url":"https://api.github.com/repos/mojombo/semver/issues/200/labels{/name}","comments_url":"https://api.github.com/repos/mojombo/semver/issues/200/comments","events_url":"https://api.github.com/repos/mojombo/semver/issues/200/events","html_url":"https://github.com/mojombo/semver/issues/200","id":33903384,"number":200,"title":"Nightly builds not supported","user":{"login":"mearns","id":5140254,"avatar_url":"https://avatars.githubusercontent.com/u/5140254?v=3","gravatar_id":"","url":"https://api.github.com/users/mearns","html_url":"https://github.com/mearns","followers_url":"https://api.github.com/users/mearns/followers","following_url":"https://api.github.com/users/mearns/following{/other_user}","gists_url":"https://api.github.com/users/mearns/gists{/gist_id}","starred_url":"https://api.github.com/users/mearns/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mearns/subscriptions","organizations_url":"https://api.github.com/users/mearns/orgs","repos_url":"https://api.github.com/users/mearns/repos","events_url":"https://api.github.com/users/mearns/events{/privacy}","received_events_url":"https://api.github.com/users/mearns/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":58,"created_at":"2014-05-20T16:05:59Z","updated_at":"2015-10-26T03:51:27Z","closed_at":null,"body":"I really like semver except for specification that all strings following the Major.minor.patch version number indicate a pre-release. I feel that this is inconvenient for, if not incompatible with, rapid development environments with development builds (e.g., nightly snapshot builds).\r\n\r\nIn my team, we do not always know what the version number of the next release will be, because we don't know what kind of changes will be ready for inclusion when it is time to release. We therefore do not bump the version number until the release. Instead, we add a \"post-release\" suffix to the version string immediately after the release. For instance, we release version 1.0.0, and then add the string \"-dev\" to the version string, so that until the next release, we are all working with version 1.0.0-dev. Nightly builds will include this suffix on the version string, indicating that it is a development build.\r\n\r\nConceptually, it is very similar to the idea of a pre-release identifier as you've described it, but the important difference is that its precedence is *higher* than the version number it attaches to. Again, this is because we don't know if the next release is going to 1.0.1 with a critical bug fix the next day, or 1.1.0 with new features sometime next month.\r\n\r\nI would love to see semver updated to support such a feature, though I'm not sure how exactly it could be incorporated without breaking backward compatibility. Perhaps this could be worked into semver ver 3.0, unless you have a suggestion for how semver can handle nightly builds."},"comment":{"url":"https://api.github.com/repos/mojombo/semver/issues/comments/151017034","html_url":"https://github.com/mojombo/semver/issues/200#issuecomment-151017034","issue_url":"https://api.github.com/repos/mojombo/semver/issues/200","id":151017034,"user":{"login":"judgeaxl","id":1620720,"avatar_url":"https://avatars.githubusercontent.com/u/1620720?v=3","gravatar_id":"","url":"https://api.github.com/users/judgeaxl","html_url":"https://github.com/judgeaxl","followers_url":"https://api.github.com/users/judgeaxl/followers","following_url":"https://api.github.com/users/judgeaxl/following{/other_user}","gists_url":"https://api.github.com/users/judgeaxl/gists{/gist_id}","starred_url":"https://api.github.com/users/judgeaxl/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/judgeaxl/subscriptions","organizations_url":"https://api.github.com/users/judgeaxl/orgs","repos_url":"https://api.github.com/users/judgeaxl/repos","events_url":"https://api.github.com/users/judgeaxl/events{/privacy}","received_events_url":"https://api.github.com/users/judgeaxl/received_events","type":"User","site_admin":false},"created_at":"2015-10-26T03:51:27Z","updated_at":"2015-10-26T03:51:27Z","body":"Just some thoughts, as I've been following this for some time, and versioning in general for many years.\r\n\r\nAs has been mentioned above, a pre-release version can not be counted on to formally follow the rules, in terms of compatibility.\r\n\r\nI tend to immediately after a release increment the minor version and attach a pre-release tag, because the next feature release will have to be a minor bump at minimum. In my case, patches are developed on the release branch and automatically get a patch bump, not on the development branch. When it comes time to release, I can make the final decision to keep that minor bump, or go full major, depending on what the changes ended up being.\r\n\r\nIf a project does publish nightly pre-release builds, then whoever wants to use them need to realize that such a release may be unstable, might not work at all, or change everything. If a team depends on nightly releases of lots of components and this causes problems, then perhaps they need to re-think their approach. If you don't want to expose that kind of uncertainty, then you kind of have to bump the versions and make actual releases instead.\r\n\r\nAs for internal users, I think they'll just have to look at the changes, or talk to the team, if they absolutely have to work off of the bleeding edge, because any amount of version numbers are not going to solve all possible problems, IMHO."}}