bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Ricardo Wurmus]

zimoun <address@hidden> writes:

> Then you ask one question: "Should Guix be volatile software?" with
> the subtitle "Software developers should avoid traumatic changes".
> Nothing more.
> Well, I answer you by trying to fill the gap. Note that "volatile
> software" is the same argument than the Ludo's concern and the
> Konrad's example. So, nothing new on the table; except you are
> starting to throw "feelings" with the "traumatic change" words.

I’m just chiming in here to say that feelings of frustration are very
valid reasons to make or object to a change.  Guix is or can be a very
important piece of software — if it remains reliable in the toolbox of
those using it.

It is difficult striking the right balance between exciting new features
that make things possible that were previously unattainable and
dependability through stable interfaces.

The Guix command line is by far the most commonly used interface.  We
can’t just claim that the Scheme API is stable (which it actually isn’t)
and change the user-facing CLI as we please.

Personally, I think that it is fine to introduce breaking changes, but
that for changes that are likely to have a high potential for annoyance
and frustration there ought to be a documented way to work around them.
Breaking changes must be communicated through version number bumps and
accompanying announcements.

While I don’t see how we can make it happen, I do find the idea of a
stable API whose version can be selected with an environment variable
intriguing and worth thinking about.  If our Scheme API is as flexible
as we claim it shouldn’t be too hard to interpose a configuration layer
between the core facilities and the “porcelain”.

I wonder what the other maintainers think about this.

--
Ricardo