From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor?= Boskovits Subject: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism Date: Sat, 21 Dec 2019 09:40:06 +0100 Message-ID: References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> <87zhfp2w11.fsf@web.de> <871rt03shq.fsf@web.de> <87zhfn3hgj.fsf@web.de> <87tv5upttv.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008ea096059a32be93" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:42164) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iiaJs-0002CF-0Q for bug-guix@gnu.org; Sat, 21 Dec 2019 03:41:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iiaJq-0002s3-ED for bug-guix@gnu.org; Sat, 21 Dec 2019 03:41:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:41626) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iiaJq-0002r0-8M for bug-guix@gnu.org; Sat, 21 Dec 2019 03:41:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iiaJq-00089b-4U for bug-guix@gnu.org; Sat, 21 Dec 2019 03:41:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87tv5upttv.fsf@elephly.net> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ricardo Wurmus Cc: GNU Guix maintainers , 38529@debbugs.gnu.org --0000000000008ea096059a32be93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ricardo Wurmus ezt =C3=ADrta (id=C5=91pont: 2019. dec.= 20., P=C3=A9n 22:32): > > zimoun 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=E2=80=99m 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 =E2=80=94 if it remains reliable in the toolb= ox 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=E2=80=99t just claim that the Scheme API is stable (which it actually= isn=E2=80=99t) > 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=E2=80=99t see how we can make it happen, I do find the idea o= f 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=E2=80=99t be too hard to interpose a configuration= layer > between the core facilities and the =E2=80=9Cporcelain=E2=80=9D. > This is something that needs consideration. I believe that the original ideas presented here, and what you say about having a stable api can be easily synchronized by naming the environment variable to something like GUIX_CLI_API_VERSION. I would propose it to be of the form 1.0.1.0, so that the first three numbers could be the current guix version. Havin it this way would allow inter releas updates bumping the last number, and the ability to easily set a new default when the major version is bumped, which implies a breaking change anyways. From there on the question would be what should be the default? I would say, that is should be .0.0.0. Does that make sense? Maybe we could come up with something simpler, like dropping the second and third number. > > I wonder what the other maintainers think about this. > > -- > Ricardo > > > > > --0000000000008ea096059a32be93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Ricardo Wurmus <rekado@elephly.net> ezt =C3=ADrta (id=C5=91pont: 2019. dec. 20., = P=C3=A9n 22:32):

zimoun <zimon.toutoune@gmail.com> writes:

> Then you ask one question: "Should Guix be volatile software?&quo= t; with
> the subtitle "Software developers should avoid traumatic changes&= quot;.
> 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 th= e
> Konrad's example. So, nothing new on the table; except you are
> starting to throw "feelings" with the "traumatic change= " words.

I=E2=80=99m just chiming in here to say that feelings of frustration are ve= ry
valid reasons to make or object to a change.=C2=A0 Guix is or can be a very=
important piece of software =E2=80=94 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.=C2=A0 We<= br> can=E2=80=99t just claim that the Scheme API is stable (which it actually i= sn=E2=80=99t)
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=E2=80=99t 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.=C2=A0 If our Scheme API is as flexible=
as we claim it shouldn=E2=80=99t be too hard to interpose a configuration l= ayer
between the core facilities and the =E2=80=9Cporcelain=E2=80=9D.
This is something that needs considerat= ion. I believe that the original ideas presented here, and what you say abo= ut having a stable api can be easily synchronized by naming the environment= variable to something like GUIX_CLI_API_VERSION. I would propose it to be = of the form 1.0.1.0, so that the first three numbers could be the current g= uix=C2=A0 version. Havin it this way would allow inter releas updates bumpi= ng the last number, and the ability to easily set a new default when the ma= jor version is bumped, which implies a breaking change anyways. From there = on the question would be what should be the default? I would say, that is s= hould be <current-mayor>.0.0.0. Does that make sense?=C2=A0 Maybe we = could come up with something simpler, like dropping the second and third nu= mber.

I wonder what the other maintainers think about this.

--
Ricardo




--0000000000008ea096059a32be93--