{"action":"closed","issue":{"url":"https://api.github.com/repos/ajoberstar/gradle-git/issues/106","labels_url":"https://api.github.com/repos/ajoberstar/gradle-git/issues/106/labels{/name}","comments_url":"https://api.github.com/repos/ajoberstar/gradle-git/issues/106/comments","events_url":"https://api.github.com/repos/ajoberstar/gradle-git/issues/106/events","html_url":"https://github.com/ajoberstar/gradle-git/issues/106","id":60374657,"number":106,"title":"Question - best practice for changing major version ","user":{"login":"plumlee","id":136463,"avatar_url":"https://avatars.githubusercontent.com/u/136463?v=3","gravatar_id":"","url":"https://api.github.com/users/plumlee","html_url":"https://github.com/plumlee","followers_url":"https://api.github.com/users/plumlee/followers","following_url":"https://api.github.com/users/plumlee/following{/other_user}","gists_url":"https://api.github.com/users/plumlee/gists{/gist_id}","starred_url":"https://api.github.com/users/plumlee/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/plumlee/subscriptions","organizations_url":"https://api.github.com/users/plumlee/orgs","repos_url":"https://api.github.com/users/plumlee/repos","events_url":"https://api.github.com/users/plumlee/events{/privacy}","received_events_url":"https://api.github.com/users/plumlee/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/ajoberstar/gradle-git/labels/question","name":"question","color":"009800"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-03-09T16:56:03Z","updated_at":"2015-03-10T15:58:49Z","closed_at":"2015-03-10T15:58:49Z","body":"Appreciate your work on the plugin. We are using the [nebula-release-plugin](https://github.com/nebula-plugins/nebula-release-plugin) in our git strategy, with long lived release branches such as `release/1.x` that branch off `master`, and all feature branches coming off `master` as well. We build continuously off changes to `master` and use the release plugin to tag those.\r\n\r\n Looking at [https://github.com/ajoberstar/gradle-git/wiki/SemVer%20Support](https://github.com/ajoberstar/gradle-git/wiki/SemVer%20Support) in how versions are inferred semantically, it seems that one way to move to a new major version (from v1.x.y to v2.x.y) without having to create a release branch would be to manually tag a commit in master as `v2.0.0`. From this, the next build triggered in master should pick up that as the nearest tag, and all future builds would increment that tag.\r\n\r\nMy use case is that we might release version 1, and decide that our next release will be version 2, but we don’t cut our release branch until we get close to a release.\r\n\r\nDo you have any other suggestions or better ways for properly using the inferred version? If this more properly belongs in the release plugin issues, I’ll post it there. "}}