From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: bug#38529: Deprecating =?UTF-8?Q?=E2=80=98guix_?= =?UTF-8?Q?environment=E2=80=99=3F?= Date: Fri, 20 Dec 2019 14:21:34 +0100 Message-ID: References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> <87k16snuoz.fsf_-_@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:34588) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iiIEH-0006QL-7X for bug-guix@gnu.org; Fri, 20 Dec 2019 08:22:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iiIEF-0002HD-Dt for bug-guix@gnu.org; Fri, 20 Dec 2019 08:22:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:40039) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iiIEE-0002Gc-7m for bug-guix@gnu.org; Fri, 20 Dec 2019 08:22:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iiIEE-000518-45 for bug-guix@gnu.org; Fri, 20 Dec 2019 08:22:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: 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: Konrad Hinsen Cc: Guix Devel , 38529@debbugs.gnu.org Hi Konrad, On Fri, 20 Dec 2019 at 12:18, Konrad Hinsen wrote: > My point of view (long form: > https://hal.archives-ouvertes.fr/hal-02117588) > is that software projects should adopt a backwards compatibility policy > early on, state it clearly in their documentation, and stick to it. That > prevents misunderstandings, bad surprises, and heated debates. Thank you for the pointer. I have not read yet. I agree with the compatibility policy and this argument has been raises in the "heated" debate with Arne. :-) > As for what that policy should be for Guix, that's a more difficult > story. For projects with versioned releases, I like the principles The first idea which comes in mind is to introduce a pledge. Maybe in the introduction. "The Guix project pledges to keep backward compatibility... blabla". However, the real question is at which level. At the CLI level? At the exported scheme functions? All modules or specific ones? > of semantic versioning, but Guix is more of a rolling-release > project. (Test question: does anyone know what the current Guix version > number is? Does anyone care?) I am not aware of any good precedents > in terms of policy for such projects. I agree. I proposed [1] to add "tags" in the meaning of "git tag". Initially, to ease the navigation through the history when searching for packages. Re-hashing this "guix tag" or "guix pull --tag" proposal, one idea could be to introduce tags, say v1.1, v1.2, v1.3 etc bumping the version every X months, or after each core-update merge, or after , then by default "guix pull" would update to the tags. This adds "stability" because we could tag commits that we know are stable (no "guix pull" break, etc.) [1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html > > The hard question then becomes: what do we call it? I vote against > > abbreviations. :-) > > > > Also, what other goals would we set for that command? How would we > > frame it in the set of commands? > > I vote for discussing the second point before the first one. Names > should reflect the functionality behind them. The starting point seems: - https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html - what do you feel missing about "guix environment"? Considering my use-case, I am mostly aligned with "The future of 'guix environment'". All the best, simon