{"action":"created","issue":{"url":"https://api.github.com/repos/sonata-project/dev-kit/issues/153","repository_url":"https://api.github.com/repos/sonata-project/dev-kit","labels_url":"https://api.github.com/repos/sonata-project/dev-kit/issues/153/labels{/name}","comments_url":"https://api.github.com/repos/sonata-project/dev-kit/issues/153/comments","events_url":"https://api.github.com/repos/sonata-project/dev-kit/issues/153/events","html_url":"https://github.com/sonata-project/dev-kit/issues/153","id":159475894,"number":153,"title":"Branch management: The three roads","user":{"login":"Soullivaneuh","id":1698357,"avatar_url":"https://avatars.githubusercontent.com/u/1698357?v=3","gravatar_id":"","url":"https://api.github.com/users/Soullivaneuh","html_url":"https://github.com/Soullivaneuh","followers_url":"https://api.github.com/users/Soullivaneuh/followers","following_url":"https://api.github.com/users/Soullivaneuh/following{/other_user}","gists_url":"https://api.github.com/users/Soullivaneuh/gists{/gist_id}","starred_url":"https://api.github.com/users/Soullivaneuh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Soullivaneuh/subscriptions","organizations_url":"https://api.github.com/users/Soullivaneuh/orgs","repos_url":"https://api.github.com/users/Soullivaneuh/repos","events_url":"https://api.github.com/users/Soullivaneuh/events{/privacy}","received_events_url":"https://api.github.com/users/Soullivaneuh/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":{"login":"Soullivaneuh","id":1698357,"avatar_url":"https://avatars.githubusercontent.com/u/1698357?v=3","gravatar_id":"","url":"https://api.github.com/users/Soullivaneuh","html_url":"https://github.com/Soullivaneuh","followers_url":"https://api.github.com/users/Soullivaneuh/followers","following_url":"https://api.github.com/users/Soullivaneuh/following{/other_user}","gists_url":"https://api.github.com/users/Soullivaneuh/gists{/gist_id}","starred_url":"https://api.github.com/users/Soullivaneuh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Soullivaneuh/subscriptions","organizations_url":"https://api.github.com/users/Soullivaneuh/orgs","repos_url":"https://api.github.com/users/Soullivaneuh/repos","events_url":"https://api.github.com/users/Soullivaneuh/events{/privacy}","received_events_url":"https://api.github.com/users/Soullivaneuh/received_events","type":"User","site_admin":false},"milestone":null,"comments":13,"created_at":"2016-06-09T18:26:10Z","updated_at":"2016-06-11T13:27:30Z","closed_at":null,"body":"Currently, we manage two branches: The stable one and the master one.\r\n\r\nThis works great, but this will make big problems when we will start releasing new majors.\r\n\r\nConcrete case with admin-bundle and core-bundle:\r\n\r\nIf we release core-bundle right now, the logic would says that 3.x is not maintained anymore.\r\n\r\nBut, admin-bundle wont be compatible with core-bundle 4.0 right now. So user will still use the legacy branch of core-bundle waiting compatibility.\r\n\r\nBut what if a bug is found on core-bundle 3.x? Should we refuse the fix? I don't think so.\r\n\r\nThis is why I propose to maintains 3 branches starting the next major:\r\n\r\n* `master`: The unstable branch, like actual (5.x for core-bundle)\r\n* `stable`: For BC features and deprecation (4.x for core-bundle)\r\n* `legacy`: For bug fixes. All bug-fixes should be submitted here except those concerning a feature added on the `stable` branch.\r\n\r\nAny suggestions?\r\n\r\nThe dispatcher has to be updated before releasing new majors."},"comment":{"url":"https://api.github.com/repos/sonata-project/dev-kit/issues/comments/225361682","html_url":"https://github.com/sonata-project/dev-kit/issues/153#issuecomment-225361682","issue_url":"https://api.github.com/repos/sonata-project/dev-kit/issues/153","id":225361682,"user":{"login":"ju1ius","id":218404,"avatar_url":"https://avatars.githubusercontent.com/u/218404?v=3","gravatar_id":"","url":"https://api.github.com/users/ju1ius","html_url":"https://github.com/ju1ius","followers_url":"https://api.github.com/users/ju1ius/followers","following_url":"https://api.github.com/users/ju1ius/following{/other_user}","gists_url":"https://api.github.com/users/ju1ius/gists{/gist_id}","starred_url":"https://api.github.com/users/ju1ius/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ju1ius/subscriptions","organizations_url":"https://api.github.com/users/ju1ius/orgs","repos_url":"https://api.github.com/users/ju1ius/repos","events_url":"https://api.github.com/users/ju1ius/events{/privacy}","received_events_url":"https://api.github.com/users/ju1ius/received_events","type":"User","site_admin":false},"created_at":"2016-06-11T13:27:30Z","updated_at":"2016-06-11T13:27:30Z","body":"> But if so then how are users supposed to find their way through the documentation ?\r\n\r\nYou didn't understand the question. Currently when **browsing the documentation website** you can select the desired bundle documentation version you want to read (the dropdown menu on the top right).\r\n\r\nIf, quote, «the `unstable`, `stable` and `legacy` are just shortcut names, that yield no meaning as regard to inter-package consistency.», then for each bundle documentation page this menu will contain completely different version numbers, with no \"breadcrumb\" or \"pointer\" to follow when reading the docs in a linear fashion.\r\nGiven that composer.json only lists **explicitely** required packages, in order to know which documentation version you should read for a particular bundle, you'd have to constantly refer to your **composer.lock**. :scream: \r\n\r\nDo you get my point ?"}}
{"actor":{"display_login":"ju1ius"}}