In that case wouldn't it also be possible to just change all instances of "0.6.x" to ">=0.6.0" within npm itself and then throw an error if you try to publish with "0.6.x"? The problem here never was a bad feature, it was bad metadata. All the metadata is in one central repository for the most part..
On Sat, Jun 30, 2012 at 2:43 AM, Isaac Schlueter <[email protected]> wrote: > Brandon, > > That's a good question. I think the answer is, "It depends." > > In some cases, you CAN just take whatever the risk is, see what > happens, then revert the change. Historically, I've done that a lot > in the npm client. However, when the problem ends up in lots of > persistent places, that can turn malignant (qv, > "engines":{"node":"0.6.x"} or require('sys').) > > Then fixing it involves either (a) use a time machine to change the > past, (b) get the whole world to update their stuff, or (c) accept > that we have made a mistake we can't fully correct. To my knowledge, > (a) was never an option. (b) is only an option if you're takling > about a small userbase, and we no longer are. So you either have to > decide to be ok with it, or come up with an approach that doesn't make > things worse. > > When `npm install` breaks, we can just fix it in the next version. A > few people will get annoyed, but the problem will be isolated. But if > `npm publish` or (in this case) `npm init` do something wrong, then it > can sometimes cause issues much later and affect many more users. > > So, if a temporary problem in npm init or publish causes a bunch of > garbage metadata to end up in the registry, and we can fix this by > changing the behavior of `npm install` slightly, that can be a pretty > good approach. > > > On Fri, Jun 29, 2012 at 11:47 PM, Brandon Benvie > <[email protected]> wrote: > > This is an honest curious question because I don't know the answer or > have a preconceived notion. Is it possible to just try a change and then > reactively revert it if it breaks enough stuff? What I do see here and in > recent compat issues is a bike load of buttshedding and only a handful of > people citing actual incidents. On either side all it amounts to are > opinions and many, perhaps most, are based on speculation of "if this > happens". I would guess many or most of those opinions have little relation > to the actual outcome and are mostly based on whatever opinion the person > has on the behavior being discussed. > > > > If actual breakage is the concern then maybe things need to be broken > when it seems plausible, just long enough to determine whether to reverse > the break or not. For certain, when it IS broken, the feedback will be > immediate and sincere. > > > > -- > > Job Board: http://jobs.nodejs.org/ > > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > > http://groups.google.com/group/nodejs?hl=en?hl=en > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
