Skip to content
This repository has been archived by the owner on Apr 18, 2018. It is now read-only.

Clarifying: stability policy on the build #54

Closed
Fishrock123 opened this issue Apr 13, 2015 · 4 comments
Closed

Clarifying: stability policy on the build #54

Fishrock123 opened this issue Apr 13, 2015 · 4 comments

Comments

@Fishrock123
Copy link
Member

This isn't something that has really been talked about in io.js.

So far the build hasn't really been considered "part of our api" in the sense that changes tend to go in and out, and sometimes "breaking" changes occur in how the build works. Usually nothing too radical, though.

I'd agree with that.
Basically if someone notifies we broke something we can either just go fix it, or if it is very obscure, ask them for a patch. Anyone depending on the build is depending on the source, so semver isn't as big of an issue either.

What are people's thoughts here?

@jasnell
Copy link
Member

jasnell commented Apr 13, 2015

One idea I've been kicking around is whether the build could actually be pushed into a separate repo with it's own history, then linked into the main repo as a sub-module. It's a thought at least ;-) .. otherwise I agree

@mhdawson
Copy link
Member

If I understand correctly the issue would be for people that build using source we might break their workflow. For minor issues I agree that we should just got fix it but the more I think about it the more important I think it is that we agree on the policy for the main tools that go into the builds and the impacts that changing them may have.

For example, requiring a new compiler may mean that you can no longer support older versions of an OS. In this context making "breaking" changes by requiring new levels of the compiler or other key tools should be carefully considered and introduced in a controlled manner. We may also need to ensure the CI does at least some builds on the oldest levels we agreed to support.

This may not strictly be "build" but the environment needed to be able to "build", but constraining our builds may be the best way to enforce what we agree is important. Either way I do think it that we should cover this as we (IBM) have to commit to our internal consumers to support particular OS levels and being forced to change compilers/supported OS levels in a minor/patch release could make that very difficult.

jasnell added a commit that referenced this issue Apr 13, 2015
per Issue #54

This is just a start. Please poke holes.
@Fishrock123
Copy link
Member Author

Yeah, I agree for new versions of compilers and stuff should only be in majors. It's mostly just little things, flags changed, etc.

Stuff like support for ninja through make being removed. (It was kinda weird to begin with.)

@orangemocha
Copy link

+1.
A good current example is the v8 upgrade to ES6 features, which requires C++ '11 language features and so makes VS 2013 the minimum compiler version on Windows, which in turn makes Windows 7 the minimum required OS for the Windows build.

The tangible impact is not just on people who build Node.js, but also on native addon modules, the majority of which is compiled at npm install time.

@jasnell jasnell closed this as completed Mar 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants