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
