-
Notifications
You must be signed in to change notification settings - Fork 18
Clarifying: stability policy on the build #54
Comments
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 |
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. |
per Issue #54 This is just a start. Please poke holes.
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.) |
+1. 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. |
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?
The text was updated successfully, but these errors were encountered: