[ochs]

The solution is easy: if you fork a project and it becomes incompatible with the upstream, rename it. How is anyone supposed to discriminate between the two versions if they have the same name?

Also, I'd say, if your software needs lots of modified dependencies, you're not communicating with those projects properly.

If every single project were to fork every one of their dependencies, the result would be maintenance nightmare.

[notacoward]

>if your software needs lots of modified dependencies, you're not communicating with those projects properly.

This, a hundred times. The OP wants to bundle modified versions of other people's open-source software as part of their own without feeding the changes upstream properly, and that's just not the right way to do things. Distributions' rules discouraging bundled packages are there because even worse things happen if everyone does that. Sometimes the dependent package has to put off packaging a new release for a particular distro until their dependencies are satisfied, but then it's time to put on big-girl panties and move on. Managing dependencies and reducing version sensitivity are part of a developer's job.

[zaphar]

A change that is only useful to you has little likelihood of being accepted upstream. Changes that are only useful to you are far more frequent than you seem to think.

[notacoward]

Don't assume you know what I think. I've had to grapple with this issue myself many times. I've had to implement nasty workarounds because upstream rejected a trivial patch. It's a pain, but spewing about how packagers all have OCD and live in the past is hopelessly egocentric and whiny . . . and counterproductive. They do know what they're doing, and their policies generally do make sense if you consider what works across thousands of packages instead of just one. Exceptions and accommodations can be made when the benefit outweighs the cost or risk, but a case has to be made for that. Throwing a tantrum isn't making a case.

[snprbob86]

> if you fork a project and it becomes incompatible with the upstream, rename it

I agree completely, but I'd like to take your idea further in a direction you likely didn't intend.

The fundamental observation of distributed version control systems, in my opinion, is: Every commit is essentially a fork.

When you combine these two ideas: 1) fork->rename and 2) change==fork, with the 3) identities & values from FP/Clojure/etc, you realize that version numbers are complete folly.

Coincidentally, I just wrote about this with respect to SemVer: http://www.brandonbloom.name/blog/2013/06/19/semver/

In short, if you have awesomelib and make an incompatible version, you can call it awesomelib2. Or you could call it veryawesomelib or whatever else you want. If you give up on the silly idea of being able to compare version numbers, then versioning and naming become equivalent.

[binarycrusader]

Version numbers only appear to be folly because proper engineering discipline has not been applied when managing the stability and/or backwards-compatibility of shared interfaces.

If more developers cared about versioning their software appropriately based on incompatible changes or stability guarantees, it would significantly reduce the costs of maintaining OS software distributions and providing integrated software stacks to users.

[dragonwriter]

> Version numbers only appear to be folly because proper engineering discipline has not been applied when managing the stability and/or backwards-compatibility of shared interfaces.

Encoding intelligence (beyond, perhaps, simple sequence) in version numbers for software is fundamentally folly.

Encoding intelligence about compatibility in version numbers of APIs is only folly to the extent that "proper engineering discipline has not been applied when managing the stability and/or backwards-compatibility of shared interfaces."

Confusing what makes sense with software and what makes sense with APIs is as problematic as any other confusion of interface with implementation.

[binarycrusader]

I think we're saying the same things.

The purpose of libraries is generally to provide an API to one or more consumers.

I'm talking about versioning as applied to the library, as a representative of a set of interfaces provided.

Not as some sort of runtime detection mechanism.

[snprbob86]

> If more developers cared about versioning their software appropriately based on incompatible changes or stability guarantees

But they don't. And you're not going to be able to make them. And even if you did, people would disagree about what constitutes compatibility, stability, and engineering disciplin. One man's "breaking change" is another man's "that was an implementation detail". It's not possible to get this right, since first you need to define "right". That's why versioning is folly.