Hi Simon, > Maybe I miss a point. It is not: "watch out, this will do something > else in the future" but "watch out, this was doing something else in > the past and the change happened the <date> in <commit>".
Concrete example: I am writing a tutorial about using Guix for reproducible research. It shows several uses of "guix environment", some of them without '–add-hoc' or '–inputs-of'. I know my examples will cease to work in a few months. What am I supposed to do about this? > First, I am not convinced that there is not so much scripts that will > be broken. And second, I am not convinced neither that these very > scripts need time-traveling. Perhaps it's just me, but I use "guix environment" quite a lot in scripts, in order to make them more reproducible. Here's a simple example: #!/usr/bin/env bash guix environment --container --ad-hoc gcc-toolchain <<EOF gcc pi.c -o pi ./pi EOF >> The first rule of backwards-compatibility is: never change the meaning >> of an existing valid command/API. Add new valid syntax, deprecate old >> valid syntax, but don't change the meaning of something that was and >> will be valid. > > I agree on the rule. > But it is mitigated but the number of users and the popularity of the tool. > ;-) Indeed! > Yes, it is probably the most adequate to do. But it is sad to loose > the good name "guix environment"... and we know that naming is hard. > ;-) I definitely agree. As a lesson for the future, maybe we should use not-so-nice names for new commands during a kind of beta-testing phase. Cheers, Konrad
