- 28 Apr, 2021 2 commits
-
-
Georges Racinet authored
--HG-- branch : heptapod-0-21
-
Georges Racinet authored
--HG-- branch : heptapod-0-21
-
- 22 Apr, 2021 1 commit
-
-
Georges Racinet authored
--HG-- branch : heptapod-0-21
-
- 15 Apr, 2021 2 commits
-
-
Georges Racinet authored
--HG-- branch : heptapod-0-21
-
Georges Racinet authored
--HG-- branch : heptapod-0-21
-
- 02 Apr, 2021 1 commit
-
-
Georges Racinet authored
--HG-- branch : heptapod-0-21
-
- 10 Dec, 2020 1 commit
-
-
Georges Racinet authored
--HG-- branch : heptapod
-
- 02 Dec, 2020 1 commit
-
-
Georges Racinet authored
--HG-- branch : heptapod
-
- 10 Sep, 2020 2 commits
-
-
Georges Racinet authored
--HG-- branch : heptapod
-
Georges Racinet authored
Of course the revisions of that file that matter are those from the release branches, but sometimes we want to work on it ahead, and it looked like an error to have nothing after 0.13 --HG-- branch : heptapod
-
- 21 Jun, 2020 1 commit
-
-
Georges Racinet authored
These files tend to have a separate life in release branches, this isn't a problem, yet's it's more practical for the version in the main branch not to lag too much. --HG-- branch : heptapod
-
- 16 Mar, 2020 2 commits
-
-
Georges Racinet authored
--HG-- branch : heptapod
-
Georges Racinet authored
For this too, there's no reason to restrict it to the Docker case only. A significant policy change is that we can't really promise anymore that unreleased changes are available in the latest Docker images. With source installs being more and more important to us, and the fact that the source version necessarily predates the Docker version, it's become too restrictive in practice. --HG-- branch : heptapod
-