-
Notifications
You must be signed in to change notification settings - Fork 569
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: Adding special features to LTS branches #5
Comments
This might not be an issue any longer. PPC support is in latest v8. Quick question though: will adding support for a new architecture break the ABI on other architectures previously supported? I also wonder if this is really an issue any longer. For previously unsupported platforms I have to assume that for at least one major release cycle the only people adopting that new platform are "early adopters" if our major release cycles are 6 months or less (which I think is our target). I think the main reason this has become an issue in node.js is the long release cycles. People are far more compelled to try and get their features in to the previous release line when the cycles are so long.
This is a double-edged sword because at least part of the stability of that prior release line is the fact that we aren't increasing the surface area for bugs with additional functionality. |
I just realized that if we only take majors for LTS we have the ability to take on new features if necessary. The only exception to this is feature additions where the ABI changes which we currently avoid in minors for current. |
@rvagg : "do we accept additional features into an LTS branch" I would say definitely no, unless they are necessary to address critical bugs or vulnerabilities. If IBM came along and wanted to add support for one of our platforms and we built that off an LTS release, we would likely handle that particular distribution ourselves rather than asking to have it added to the LTS branch; we would definitely, however, want to see about getting support into master moving forward -- which means us doing the work necessary to maintain support at the current v8 level. @mdawsonibm -- any additional thoughts here? |
I agree that we don't want to be adding "features" to an LTS. We get pushed to do this in more traditional product so I could regret saying this but I still think the starting point should be "no". The only exception would be to address security issues that might have some of the same characteristics of what would normally be considered a "feature" |
I agree with all of these sentiments, just trying to tease apart the underlying issues. A more pertinent example might be mdb support by Joyent. Their business model for mdb in Node involves people being able to take an mdb-compatible core dump from a Node progress and uploading it to Manta (or something like that). But mdb support in Node requires a bit of work getting the all the jit symbols in place so you can expose them through the dump. I suspect that one of the reasons they are hesitant to upgrade V8 in joyent/node as quickly as others would like is that rewriting mdb-support each V8 release would be too people-time-intensive. But an LTS release would help with that of course since they have a stable base to build on. However, if they can't bundle in stuff to an LTS branch that doesn't live in a bleeding-edge branch then they are only left with the option of distributing their own LTS-based binaries for people to use. I'm not saying I want to support this type of model, but it's worth discussing. |
I'm sure lots of vendors would love to add those kinds of things into Just thinking out loud... Perhaps one way of doing it would be to introduce
|
If the only one building and testing the code in the contrib directory is the vendor, I am not sure it makes a lot of sense for the code to live in the main project. A little bit tangential, but I haven't seen this discussed elsewhere. How would the trademark policy intersect with vendors shipping their own patched LTS version? |
It may also come down to what is considered a "bug". If the support required for mdb in Node was broken by v8 upgrade I don't think I'd be opposed to that being fixed in an LTS release. Some cases where it is too difficult to keep up in master might be addressed by allowing "fixes" to restore earlier functionality. |
No. No new features. It's way more important that shit doesn't break than it is to get new features into an LTS. BUGFIXES ONLY. |
A LTR should be so conservative it's physically painful. |
Joyent alone doesn't upgrade V8 in node. The Node.js core team, the contributors and the project makes this decision together. The core team decided not to upgrade V8 before releasing v0.12.0 because it would have happened too late in the release cycle, and the majority of the team wasn't comfortable with delaying the release even more to give it enough time to be tested properly . If V8 had been upgraded, mdb would have been updated at some point, but it certainly wasn't a reason not to upgrade.
I don't think any change made to mdb_v8 to support changes in V8 would be breaking node in any way. The changes usually add/remove/modify symbols to be generated by /cc @davepacheco so that he can weigh in and confirm/inform since he's done a lot of the work on mdb. |
Yeah, @misterdjules's summary about the mdb work is accurate. |
The mdb_v8 support won't be an issue if Joyent invests a little more in keeping it up-to-date in upstream V8. |
This might be controversial and perhaps the answer is a simple no. One of the advantages of an LTS branch for companies that are extending Node/io.js is that they have a stable foundation to work on.
Two examples of this are:
With an LTS, we have a stable V8 to work with which makes it easier for companies to use as a foundation for additional changes.
So the question is - do we accept additional features into an LTS branch? If IBM came along with POWER support or Joyent wanted mdb support would we be willing to even discuss it or are these pure base-releases and any extension has to happen in a release channel that they create on top of what we release? The version numbering would obviously be kind of awkward because we're likely talking about feature additions, therefore minor-version bumps, but I'm sure we could get creative with this (maybe we claim the next minor-version bump for an LTS and standard releases have to bump two minor-versions to continue).
Discuss.
The text was updated successfully, but these errors were encountered: