Iterator groupby 2

[hdgarrood]

Like #87, but this is not a breaking change, and I prefer this API - it seems easier to use correctly.

[paf31]

👍 Looks great, thanks for putting the new version together!

[hdgarrood]

🎉

[paf31]

Is adding a dependency considered a breaking change? I don't think it matters very much in this case. I just stumbled over it while updating the package set.

[hdgarrood]

I'm not sure, but I'm not aware of any reason to treat it as a breaking change

[paf31]

Ok, well for now I'll just leave arrays at 3.1.0 in the package set, but obviously it should be updated to include this change at some point.

[hdgarrood]

What makes it difficult to use the latest version?

[paf31]

Just that package-sets requires us to list all transitive dependencies in packages.json, so now every reverse dependency of arrays needs unsafe-coerce.

[garyb]

I could think of a somewhat convoluted way in which it could be breaking:

• In my project I depend on unsafe-coerce 1.0.0
• I also depend on arrays^3.0.0
• arrays climbing to 3.2.0 demands unsafe-coerce 2.0.0... oops

I think there is almost zero chance this could be the case in this particular instance, but it would seem that adding dependencies could theoretically be breaking.

[natefaubion]

I agree with @garyb. If bumping major versions of dependencies is breaking, then adding dependencies is breaking as well, I'd think.

[hdgarrood]

If that counts as a breaking change then any modification of dependency version bounds could count as a breaking change, I think, because people are free to use any form of version constraints (we can't assume everyone uses ^ constraints everywhere).

Imo it makes more sense to let bower to handle a case like this. I expect it is able to but haven't tested.

[hdgarrood]

Have we considered separating dependency information (x depends on y) from package sets (x v1.2.3. y v2.3.4, etc all work together)?

[paf31]

Well, this wasn't the only case, even recently. generics-rep recently had a similar change, which also broke the package set upgrade process.

[natefaubion]

I think, in a perfect world it would not necessarily be breaking because you could have multiple versions in single build. But the issue is whether or not upgrading a minor thing can break your build (the definition of breaking). If this can cause conflicts (breaking your build), then it needs to be a breaking change.

[hdgarrood]

Likewise bumping major versions of deps is only breaking because people might be importing modules from that dep via a transitive dependency, ie without explicitly listing it as a dependency local to that project. If we made it like Haskell where you have to list something as a dependency to be able to import it we would be able to lift this restriction. I'd very much like to do that eventually.

[natefaubion]

Haskell can also deal with multiple versions in a build though, can't it?

[hdgarrood]

It doesn't break your build though, unless you increase the lower bound in your bower.json. bower should just continue to use the older version.

[natefaubion]

It doesn't break your build though, unless you increase the lower bound in your bower.json. bower should just continue to use the older version.

Yes, I'd agree if you can have an appropriate lower bound, then that works.

[hdgarrood]

Kind of, but not very well. You can have multiple versions of a package together in a global package db but nobody does that any more since cabal sandboxes and stack afaik.

[hdgarrood]

Well, this wasn't the only case, even recently. generics-rep recently had a similar change, which also broke the package set upgrade process.

The way I see it this problem is caused by the package set upgrade process not being able to take version bounds into account

[natefaubion]

Likewise bumping major versions of deps is only breaking because people might be importing modules from that dep via a transitive dependency

I agree with this (using transitive dependencies is bad), but it's used all over the place in the ecosystem, and it's mainly done to avoid dealing with version bounds for simple things that don't change (like Maybe and Either).

[hdgarrood]

Maybe we can make it more comfortable to list all direct dependencies in bower.json with tooling.

[natefaubion]

So another point for "not a breaking release", unsafe-coerce@2.0.0 is the version for the 0.10.x compiler release. So in this case, nobody could have been using arrays@3.x with an earlier unsafe-coerce.