0.2.1 - bump bitballoon version to use graceful fs

[jescalan]

If you reinstall/update ship it will automatically bump this version for you without this change

[samccone]

fuzzy deps are so dangerous :| +1 for locking it down

[jescalan]

I don't really agree here. There's nothing breaking in 0.2.0, and the bitballoon deployer works fine with it, 0.2.1 just contains a bugfix for a specific issue we were having. But since it just came out, we get a free auto-upgrade by just updating ship.

I'll lock up at a specific version if there's a bug with ship that requires that version, but this one is a bug with bitballoon, which they solved and can be upgraded cleanly as soon as they release.

[joshrowley]

:+1:

[jescalan]

Like for example, if bitballoon releases another minor edge case bugfix, does that mean I should upgrade the deps to 0.2.2? That means we have to come back and update every package every time a patch is released, which seems like overkill. And what if that bugfix actually broke someone else's code somehow, then they couldn't downgrade back to a version that still does work perfectly fine with ship and for their project?

I just feel like our locks should bottom out at whatever version still works with the host library. Above that for patches or small feature adds to the dependency, the user can still get them by upgrading but is not forced to.

[joshrowley]

@samccone why is using ~ a bad idea? am i misunderstanding the syntax, doesn't it mean use any patch level >= 0.2.1 which would just be slightly more specific than 0.2.x

your argument makes sense @jenius

[samccone]

fuzzy deps assumes everyone in the world is following semver sure the bitballoon package might, but do all of their deps follow it?

The chain just goes deeper and deeper, you are safest locking down all of your deps so that installing the project a week or a year from now still works.

This is a real issue and something that has burned marionette, backbone, bower and many many more.

[joshrowley]

oh ok, so your argument is not just against ~, but 0.2.x as well, and would prefer to have everything down to the patch level specified.

[notslang]

If people aren't following semver, the that's a bug with their package. I don't know why we act like the versioning scheme is optional with node. Npm uses semver so that's what you need to use. If anyone breaks that expectation, then it's their problem and their package should be fixed or forked.

[joshrowley]

well, it's not really just their problem, it would be our problem as well, no matter who's to blame it still screws us and people using our software right?

[jescalan]

Yeah maybe for a project that's super high visibility and mission critical that a bug with a dependency never happens, even one that can be quickly fixed once caught, I'd lock it down all the way. But it makes general development and maintenance significantly easier when you assume that people are using semver correctly.

Most of the reason here is that if there is a bug with one package, or that package is not following semver, you can just lock that down and publish a patch to fix that error within minutes of the error being caught. But I maintain a huge number of open source libs and have not been frequently bit by this, and not locking all the way down has saved me a ton of time and effort on multiple occasions where I don't have to spend all my time updating dependencies and re-publishing projects every day.

[notslang]

I'd still use "loose" deps for a mission-critical thing because I need to be alerted when patches come in from my deps. I'd just make sure to run tests before deploying that application with the updated deps... maybe even track node_modules in the VCS if I'm really paranoid.

And yes @joshrowley - it becomes our problem, but fixing it by applying special rules to the way we specify dependencies isn't the "right" way to do it. It's fixing the package that's causing the problem - and doing that will save everyone else the pain of using locked-down deps.