On Thu, Mar 17, 2016 at 7:06 PM, Robert Goldman rpgoldman@sift.net wrote:
I think the central point of difference between you and me is that you think of this as a moral issue, whereas I think of this as an issue of providing a service that fits a case that occurs, about which I don't have strong moral feelings.
No, I use the "moral" vocabulary with no stronger feelings than you have about providing a service that fits a case that occurs. My "should" and your "fit" are actually the same concept under different names. — My apologies for any misunderstanding due to this mismatch in vocabulary being used.
I believe the central difference between our stances is that I have recently come to clearly distinguish the two roles of USER and of INTEGRATOR, that most people seem to confuse at times, and maybe you included at this time.
As a USER of library XMLS, you have no right to exclude future versions. That's just not one of your prerogatives. If you're permanently unhappy with the new versions, you can fork project XMLS, but you can't declare the future out of existence.
As an INTEGRATOR of a project that uses library XMLS, you're very much dealing with the present, and indeed, may and sometimes MUST include unreleased patches to it, and/or withhold upgrade to a new version with unresolved issues. That's not just your prerogative, that's your duty and the whole point of your job.
As a WRITER of library XMLS, you get to specify the right way to use it, to deprecate old usage patterns, etc. If you frequently break things under the feet of your users without offering a simple way to upgrade and without sending patches to your known users, you'll piss them off and maybe they'll fork the project under your feet eventually or attempt a hostile takeover. Then there will be two projects with distinct names and/or even more confusion. So be nice, and try to offer them easy upgrade paths, etc. But ultimately, you're the master of your ship, and if you decide an old API was buggy, a concurrency and/or security issue, an unsalvageable mess that cannot be saved — it's your call to tell your users to man up and adopt the new better API that solves those essential issues. Or maybe you should be forking your own project and changing its name if fixing it requires a completely new API and there's no plan to support existing users.
Often, the same developer wears multiple caps part-time: co-WRITER of a library A, USER of it in some system B you also co-write, and INTEGRATOR of some application C that includes it. That's OK. But keep things separate.
As a WRITER of system B and USER of library A, you can read the git repo of A, but cannot assume write access to it. And you just cannot assume that every future INTEGRATOR of every future application C1...CN will be using any particular version of A; indeed an "emergency due to an imminent deadline" may very well force each of said INTEGRATOR at completely different times to each include an urgent security patch to A, or a forced upgrade, etc. Unless system B is never ever used by any other application than a single application C, you just cannot assume control over C when you write system B. And if you can, then B is actually C and specifying a prohibition on future version adds little or nothing to the exact version of A recorded in the source control for C: as an INTEGRATOR, unless a mere USER, you *do* keep each and every dependency under source control.
Note that in the case of ASDF, the WRITER of ASDF is both the writer of a library, ASDF itself, and or an application, ASDF-TOOLS that tests ASDF. As the former, you specifically want to NOT specify any dependency, as ASDF the library must be capable of running with any and every past present and future version of every non-broken system. As the latter, you're an integrator and want a completely reproducible set of libraries based on which to run your tests. Our current use of git submodules addresses both usage cases, though awkwardly so. Another solution might be to split ASDF-TOOLS into a separate repository indeed.
The .asd file for system B is authored by the WRITER of B who is as such a USER of A, and has no control or relationship to the INTEGRATOR of C.
To be honest, I don't see why you are so exercised about this. If you don't want to use an upper bound: don't. For the rest of us, who would like it, why does it bother you so much for us to have it?
Maybe because I just quit my job over this very issue.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Paradoxes only exist in language, not reality. — Eric S. Raymond