asdf version dependency

[Faré]

On Thu, Mar 17, 2016 at 7:06 PM, Robert Goldman <rpgoldman at 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