{"action":"created","issue":{"url":"https://api.github.com/repos/iojs/LTS/issues/3","labels_url":"https://api.github.com/repos/iojs/LTS/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/iojs/LTS/issues/3/comments","events_url":"https://api.github.com/repos/iojs/LTS/issues/3/events","html_url":"https://github.com/iojs/LTS/issues/3","id":66435005,"number":3,"title":"Discussion: TLS branch selection & lifecycle","user":{"login":"rvagg","id":495647,"avatar_url":"https://avatars.githubusercontent.com/u/495647?v=3","gravatar_id":"","url":"https://api.github.com/users/rvagg","html_url":"https://github.com/rvagg","followers_url":"https://api.github.com/users/rvagg/followers","following_url":"https://api.github.com/users/rvagg/following{/other_user}","gists_url":"https://api.github.com/users/rvagg/gists{/gist_id}","starred_url":"https://api.github.com/users/rvagg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rvagg/subscriptions","organizations_url":"https://api.github.com/users/rvagg/orgs","repos_url":"https://api.github.com/users/rvagg/repos","events_url":"https://api.github.com/users/rvagg/events{/privacy}","received_events_url":"https://api.github.com/users/rvagg/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-04-05T12:45:09Z","updated_at":"2015-04-07T20:41:41Z","closed_at":null,"body":"The intent of this issue is to gather some initial discussion on how to run a TLS process. Ultimately this is up to the working group to decide but feedback is important here.\r\n\r\nI don't think this needs to be pinned down firmly any time soon, we can start simple and ease in to it, ramping up the _serious_ as we go along and work it out. That would be my preference anyway. For instance, I'd like to propose that our first LTS is very soon, perhaps to coincide with the next V8 release, and we announce support for only 3 months with the option of extending that later on. Then we can build momentum around the process and iron out any wrinkles. Beyond that, we can brainstorm some possibilities of how this is run.\r\n\r\nThese are just some options that come to mind for me to start the discussion.\r\n\r\n## Option 1: Major-version-based LTS releases\r\n\r\nIn this option we would run an LTS branch as soon as the first minor is bumped after a major, and we'd stick with only patch releases in the strict semver sense. How long they are supported is a matter for further discussion.\r\n\r\nOne positive about this is that it's easy to understand and communicate.\r\n\r\nThere are multiple negatives though. It assumes we'll have major-version bumps regularly, which may not be the case given the pain they're going to cause. We also can't do anything time-based with these branches other than how long they exist for.\r\n\r\n### Example\r\n\r\n1. Standard io.js release train moves from `2.0.4` to `2.1.0`, an LTS is triggered.\r\n2. A `2.0.x` branch is created to run the LTS.\r\n3. `2.0.5` is cut as soon as there is something to warrant it, all patch releases from `2.0.5` onward are part of the LTS.\r\n4. Standard releases continue as usual.\r\n\r\n## Option 2: Regular time-based, non-overlapping LTS releases\r\n\r\nIn this option we would have a time period that would trigger a release, perhaps 6 or 12 months. This would be a little like the way Ubuntu does standard releases (not LTS). At the appropriate date, we would take the current _major.minor_ and use that to start an LTS branch. There would be a period of time where there's overlap between standard and LTS so we probably wouldn't end up making actual LTS releases until the next minor bump for standard releases.\r\n\r\n### Example\r\n\r\nWe're doing a 12-month cycle starting 1-May each year.\r\n\r\n1. Standard io.js release train is at `1.9.2` as we roll over in to May.\r\n2. As soon as there is a major-version bump to `1.10.0` we create a `1.9.x` branch and LTS starts where standard releases left off in that minor.\r\n3. Standard releases continue as normal.\r\n\r\n## Option 3: Regular time-based, overlapping LTS releases\r\n\r\nIn this option we do the same as the previous but we are maintaining multiple LTS branches at the same time. The overlap allows people a smoother upgrade path than the strict stop/start of option 2. The amount of time we run an LTS differs from the amount of time between creating an LTS branch. Perhaps 18 months for the lifecycle and 12 months between each LTS branch creation, giving a 6 month window for upgrading between LTS.\r\n\r\n**Variation 1**: Time period is the same as the amount of time between creating an LTS branch but we run 2 (or more?) LTS releases, staggered by 6 months, so we're always creating a new LTS each 6 months and run them for _X_ months each, where _X_ could be 12 months or more.\r\n\r\n**Variation 2**: We have two different classes of LTS and we create something similar to the Ubuntu process. We have a long-running one one that runs for a shorter time. So for example, we could make a new LTS every 6 months like Ubuntu does and only support them for 6 months but every _X_ LTS branch is supported for an extended period, perhaps every 3rd gets supported for 24 months or more.\r\n\r\n## Discussion\r\n\r\nSo, given those ideas, let's discuss LTS models that we know work well in the wild and how we can adapt those ideas to what we have to work with in io.js.\r\n\r\nThe major concern I have with io.js is that supporting V8 for longer than a stable version of Chrome is going to be on our heads. However, it's somehow managed to work for Node.js 0.10 for >2 years now so perhaps it's not going to be all that hard. I think the main risks are security-related, we'd be the only eyes supporting that codebase so we'd better have people that understand it.\r\n\r\nThere is also the issue of possible extension of LTS. There was a suggestion, floated early in the life of io.js (or was it node-forward?) that _\"if someone wants to contribute then the can keep a branch alive\"_, or something to that effect. I'm uncomfortable with the looseness of this approach because it becomes difficult to communicate exactly what kind of support a particular release train has from the io.js team. I would rather leave it to the LTS WG to make decisions about precisely what the lifecycle of an LTS branch is and if, for instance, a company was to step forward and say that they are willing to throw engineers at a branch to make it live for 5 years and the LTS WG became convinced this was possible and acceptable then they could make it happen. The alternative is to let people release their own versions outside of the official io.js banner, which may work great for situation like IBM wanting to continue releasing POWER-specific versions beyond a standard LTS cycle. This is all open for discussion of course."},"comment":{"url":"https://api.github.com/repos/iojs/LTS/issues/comments/90726165","html_url":"https://github.com/iojs/LTS/issues/3#issuecomment-90726165","issue_url":"https://api.github.com/repos/iojs/LTS/issues/3","id":90726165,"user":{"login":"mikeal","id":579,"avatar_url":"https://avatars.githubusercontent.com/u/579?v=3","gravatar_id":"","url":"https://api.github.com/users/mikeal","html_url":"https://github.com/mikeal","followers_url":"https://api.github.com/users/mikeal/followers","following_url":"https://api.github.com/users/mikeal/following{/other_user}","gists_url":"https://api.github.com/users/mikeal/gists{/gist_id}","starred_url":"https://api.github.com/users/mikeal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mikeal/subscriptions","organizations_url":"https://api.github.com/users/mikeal/orgs","repos_url":"https://api.github.com/users/mikeal/repos","events_url":"https://api.github.com/users/mikeal/events{/privacy}","received_events_url":"https://api.github.com/users/mikeal/received_events","type":"User","site_admin":false},"created_at":"2015-04-07T20:41:41Z","updated_at":"2015-04-07T20:41:41Z","body":"Comparisons to Chrome don't really work. Chrome has an auto-updated which is transparent to customers. Updating io.js is much more involved and potentially requires a recompile of addons or writing fixes or taking new versions of dependencies to deal with incompatibilities.\r\n\r\nI don't think it's a good idea to set an arbitrary timeline like 5 years. We should use download and npm statistics to see which versions are still actively used, as well as surveying a few companies that host a lot of io.js apps. Let the usage drive the support length, along with the availability of contributors who care enough about a particular release line to continue to write patches."}}