1.0.0 #8104
Comments
|
Hear, hear:+1: |
|
👍 |
|
Wait, aren't we already on version 10 or something like that? I always thought the dot in front was just a cool node thing. |
|
But pre 1.0 means it's still |
|
But what about Streams 4??!!? |
|
|
👍 |
|
+1 this is basically how node works right now except with a really weird versioning scheme. i don't mind if we go all chrome on the versioning. |
|
And have the community end up in a Python 2/3 state? That'd be awesome! /s Now, tell all the native module authors with a straight face that we have a stable version. v0.10 uses 3.14 which is so ancient that it doesn't even receive security fixes anymore. Great way to run your production systems for sure. Luckily there's now @rvagg's https://github.com/rvagg/nan that'll ease the transition, but at the native module level (which a lot of devs indirectly rely on) devs are totally screwed. One of the goals of Node was that once 1.0 was reached there would be roadmapped only one possibly breaking change per major version. That way everyone can stay up-to-date with the latest stable and minimum pain. Also, it would be nice to have even a smidgen of a standardized way to monitor/debug your applications without needing to "duck-punch" every function in core. Think our definitions of what a 1.0 means pretty well differs.
Well, you know, it's pretty difficult keeping up with needing to triage and then respond to useless issues like this with as small a team core has. So if they're so bad, why don't you help out instead of just bitching about it. |
|
The version approach of Node.js doesn't matter. I know developers who use 0.8, 0.10 and 0.12 in production. The only matter is breaking changes / backward compatibility. That's it. Also I can't see any benefit, healthy debate, etc. in this issue post rather than giving tension to Node.js core team. Also v1.0 already explained/mentioned last year - https://www.youtube.com/watch?v=82hJbjqbIt4&feature=youtu.be&t=3m45sI and I would like to know that if there is any changes on it. |
|
using in production != production ready |
|
production === pay the bills |
|
Speaking of native modules, I'd also like to see the outcome of gyp vs gn ahead of "1.0"; https://groups.google.com/forum/#!topic/nodejs/0QiIr7jr2iY. |
|
TJ, go home. You don't even do node anymore. |
|
I do "do node", we still use it at segment 👍 |
|
Semvar isn't just for your own connivence or sentiment. I kept faker below 1.0 for years for no good reason besides not feeling like it was done. Which stupid. It was 1.0 forever and a day. But I simply suck at FOSS and will not deny that I need to get better. But that's what we are doing at this point. Chrome is version 36 but node after five years isn't even 1.0.0 they're just numbers people. We need to own that this is production ready and we trust it. |
|
@trevnorris we have an entire community around semver except for node. The only reason you get stupid drama about versions is because you pretend it has some special meaning. You number your API and change it accordingly. Nobody fucking knows what the plan for node is. Now more than ever. When @isaacs set course on the 1.0 and done path, it was 2-3 years ago and everyone was sure it will be done a year later. Reality is that you no longer can pretend this is a 0.x experimental effort you can mess around with. It's time for the core team to catch up with the community they serve and stop playing games. |
|
@trevnorris I am appalled by your behavior. Eran is one the biggest champions on the community and has lead what is arguably the most successful deployment of nodejs ever. While he has a certain style of prose which you might personally not like, you will find many (like myself) agree with him. Node is as healthy as the feedback it gets from it's users. By behaving this way you hurt the project, and diminish the public perception of node core. Your comment looked snarky at best, you very obviously did not consult with the rest of the core team about this (not enough time) and close the conversation. I think we had established this was not the way to behave here in a previous occasion. seems like I was wrong and lesson is not learned. Please do reflect your actions |
|
@dscape Get off your high horse, jesus christ. I don't care too much about what the number's called, but I do sometimes feel like node's scared of growing up. It outgrew its krazy mad scientist hackerzz vibe ages ago, and maybe it's time to own that. Being an adult is scary, I get it (I really do!), but I think the fact that The Man has been using node for some time is testament to it being ready. |
|
👍 We really expect the 1.0.0, and we really shall build together to get it done!!! |
|
I don't have a strong opinion about the version numbers of Node itself. But in the NPM module community it appears, at least for the 100+ modules used in our projects, that:
If there is anything Node itself could do to set a strong example and encourage module authors to clean things up, lots of use mere users would appreciate it a lot. |
|
This is a cray thread folks. Version number smersion number. I think there are enough brilliant people working on the node core who have a noble goal of 1.0 and the right insight to determine when node is stable enough to be at 1.0. I'll consider node 1.0-ready when I don't have multiple hundreds of notifications from this repo at the end of every week :-) In reality, the only thing that matters is that you/we are comfortable deploying node in production. The number attached to it is simply an indication of progress. I am comfortable knowing node is stable enough for a reliable, major deployment. As far as I am concerned, the version number is just a progress indicator to the folks who monitoring progress. Also, let's not hurt each others feeling :) |
|
from semver.org:
question: is |
Yes, this could be improved a lot. It would be nice to have a more vocal roadmap. @tjfontaine is somewhere but we don't really know from him as the lead maintainer what exactly the plan is. Basically if we could get a more open and understandable lead, and then more outside contribution work, that'd be great. Now there's just the 'do'-ing part about that. :p |
It follows classic even-odd numbering system. As countless npm modules show, following semver is a bad idea anyway. |
|
@rlidwka: awesome. it's cool if |
|
Semvar hasn't failed you just aren't following it. |
|
@FotoVerite semver is intention at best, which is fine for most cases I've found, you can still lock things down with npm-shrinkwrap. It's not hard to introduce unwanted side-effects at the patch level even if APIs are not broken etc. I still sort of like semver, but I would rather it just be |
|
This is getting slightly toxic, let's keep it civil eh? I'm not sure closing the issue straight out was the best approach to this either but this is ultimately in the hands of the core team and the best we can do on the outside is apply gentle persuasion and use solid objective arguments rather than escalating this into a fight. |
|
Please don't confuse my tone for any signs of aggression. I also didn't take @trevnorris response in any personal or offensive tone. This thread is more of a joke than a serious discussion. I am dead serious about wanting node to be 1.0.0 but this was never meant to be a serious discussion. And look, I'm not even making any nasty comments about @tjholowaychuk! |
This is a place for technical discussions, not for nasty comments about not making nasty comments... |
For this (well-put) reason, among others, I too am in favor of getting Node to 1.0 ASAP. @trevnorris, I hear what you're saying, but do you really think that we're going to stop having major ABI changes post-1.0? I've heard some of the discussions around I think Node has outgrown the idea that Node 1.0 is somehow a finished, immutable thing. Ultimately a version string is just an identifier for a release, but as a community we have more or less hitched our wagon to semver, and we might as well try to make it work. |
|
Another "pre 1.0" checkbox: I think libuv as a library provider needs to mature. Every time node gets bumped it requires a new version of libuv as well. Since it's baked as part of the nodejs built most people doesn't care, but if you try linking nodejs to a shared build of libuv you'll start noticing that it changes. A lot. |
And why shouldn't the 1.0 release have some special meaning? I pretend to believe that enterprise level deployments won't have to overwrite native Node functions just to do simple things like gather metrics. I also pretend to believe that we'll be able to deliver a road map that gives some sort of sanity and mostly painless path to upgrade. These things, apart from API stability, are what I would consider an important part of a 1.0 release. (@othiym23 the following addresses you too) And don't forget that V8 moves faster than a road runner on crack, and stops delivering security fixes after a couple versions. Figuring out how to work with this is also an important issue. How can we pretend to deliver a stable (and I'm not talking about API) and reliable release when our major dependency is using the same release scheme we are. Want to talk about bumping major versions when breaking the API? Go talk to the V8 team who's basically broken every possible API (multiple times) in 3.x.
Who is saying this is an "experimental effort"? Granted the v0.12 release has taken longer than it should have, but have you seen us constantly changing APIs for the majority of what's already in place? We want to make sure that a 1.0 release means developers have a standard, core supported, set of tools to monitor what's happening within their application so that software that runs in "serious production environments with billion of dollars at stake" can monitor what's going on in a uniform way. Setting this as a prerequisite for 1.0 is not out of the question.
Funny, pretty sure we cut the v0.12 branch today and are working our asses off to finish up the final bits to get out the release. We've (the core committers) have discussed many times whether v0.12 should be 1.0 and the consensus was no. So, this issue was moot at best.
No. In fact I hope for Node to continuously, but gradually, evolve over time and always improve. Above I've explained the last thing I'd expect to be available from core before it's considered 1.0 ready. That is, a standardized way of seeing what's happening within my application. IMO the biggest complaint about Node is the poor debug-ability. 1.0, to me, means an application that's ready to be run in production. And, IMO, an application that's ready to be run in production should have a way to see what's happening inside. Without needing to hack around core's internals. This last bit of functionality is what at least I am hoping to solidify during v0.12, and from previous discussions with @tjfontaine he see's v0.12 as 1.0-pre. During this time we'll be working on a core supported module to deliver debugging and metrics users are looking for. Along with, what I've been looking forward to for over a year now, ripping apart the guts and making everything faster! |
First of all, it's not true. Most of the modules routinely break things on minor, and some modules (notably including npm itself) break things in patch releases. Secondly, we only care about semver because npm forced its version mask on all modules, which is a wrong thing to do by the way. Current odd-even version numbering system in node is great, and there is no reason to change it. If we're concerned about ABI, maybe also borrow OpenSSL versioning suffix? |
|
Yes the infighting will make everyone think node is production ready. If 0.12 isn't 1.0.0 fine. But stop acting like semvar is something we're getting rid of and complaining about an issue that's already present and or taking pot shots at anyone. THIS GOES FOR ALL OF YOU. This shouldn't be about anyones ego, just doing the best we can for the community. Yet I continually see people getting offended over a damn number. It's a number, we all do work with node we all care about it. Semvar needs fixing fine, fix it. Node not ready to claim 1.0.0 because of reasons fine, fix it. But do not put down anyone else because they have a differing viewpoint on this complicated issue. Show solutions not a fucking pissing contest. |
|
The only thing that could make 0.12 come out later would be re-scoping it to be 1.0. Can someone please close and lock this? |
and others
How long are we going to maintain this farce pretending that we are not already in 1.0.0 territory? We are completely handicapping ourselves from being able to do minor releases. Everything is either a major painful breaking release or a patch. We are running this project in serious production environments with billion of dollars at stake but don't have the confidence to call it for what it is.
Node is now on version 5.0.30 no matter what silly picture we are trying to project. We are a group of serious developers acting like children with the idiotic worshiping of the sacred "1.0 ". Time to grow up and realize that we all look like amateurs pushing this project for 5 years without a 1.0 in a process that is broken beyond marketing.
I don't want the next release to be 1.0.0. I want THIS ONE to be 1.0.0. And yes, there will be a 2.0.0 when we break stuff, like remove domains completely and that's a good thing! It will properly communicate to the now huge community what the new version means without having to read the (always) crap documentation about breaking changes.
It's about fucking time.
The text was updated successfully, but these errors were encountered: