From oleg.grenrus at iki.fi Thu Sep 3 10:48:43 2020 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 3 Sep 2020 13:48:43 +0300 Subject: cabal-install-3.4.0.0-rc2 and Cabal-3.4.0.0-rc2 are now available Message-ID: <9e6112a5-2f20-46c5-dc40-48169e476e52@iki.fi> The Cabal developers are happy to announce the first release candidate for cabal-install-3.4.0.0 The corresponding tag are `cabal-install-3.4.0.0-rc2` and `Cabal-3.4.0.0-rc2`     https://github.com/haskell/cabal/releases/tag/cabal-install-3.4.0.0-rc2     https://github.com/haskell/cabal/releases/tag/Cabal-3.4.0.0-rc2 and there is a handful of binaries available at     https://oleg.fi/cabal-install-3.4.0.0-rc2/    Ubuntu-16.04 bindist should work on most recent Linux distributions, (requires at least kernel 3.15, compiled against glibc-2.23). Similarly darwin-sierra bindist should work on newer macOSes as well. Since the first release candidate (rc1) following issues were resolved: - Bump process version required for job support to 1.6.9 https://github.com/haskell/cabal/issues/6986 - GHC-8.12 is GHC-9.0 https://github.com/haskell/cabal/issues/7019 - cabal-install-head v2-install fails to process source-repository-package https://github.com/haskell/cabal/issues/7007 cabal-install-3.4 release highlights are: - Support for upcoming GHC-9.0 - Removal of sandboxes - Improved public sublibrary support - `active-repositories` configuration - Various `cabal init` improvements - Various `cabal sdist` improvements - `source-repository-package` are not treated as local packages - Added `list-bin` command Complete release notes (drafts) are at: https://github.com/haskell/cabal/tree/master/release-notes Please do test this release and let us know if you encounter any issues: https://github.com/haskell/cabal/issues - Oleg P.S. Unfortunately I discovered yet another bug in cabal sdist behavior,      which is triggered if you have packages with data-files.      So there will be third release candidate. From oleg.grenrus at iki.fi Mon Sep 14 14:32:42 2020 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Mon, 14 Sep 2020 17:32:42 +0300 Subject: cabal-install-3.4.0.0-rc3 and Cabal-3.4.0.0-rc3 are now available Message-ID: <3e1c078e-038f-82a5-cca3-b1b35f1fff2b@iki.fi> The Cabal developers are happy to announce the third release candidate for cabal-install-3.4.0.0 The corresponding tag are `cabal-install-3.4.0.0-rc3` and `Cabal-3.4.0.0-rc3`     https://github.com/haskell/cabal/releases/tag/cabal-install-3.4.0.0-rc3     https://github.com/haskell/cabal/releases/tag/Cabal-3.4.0.0-rc3 and there is a handful of binaries available at     https://oleg.fi/cabal-install-3.4.0.0-rc3/   Ubuntu-16.04 bindist should work on most recent Linux distributions, (requires at least kernel 3.15, compiled against glibc-2.23). Similarly darwin-sierra bindist should work on newer macOSes as well. Since the second release candidate (rc2) following issues were resolved: - Regression in cabal repl handling of `-z` flag   https://github.com/haskell/cabal/issues/7039 - Allow Win32-2.9.0.0   https://github.com/haskell/cabal/issues/7040 - v2-update updates file+noindex repositories cach   https://github.com/haskell/cabal/issues/7061 - Fix cabal sdist issues for packages with data-files   https://github.com/haskell/cabal/issues/7028 Since the first release candidate (rc1) following issues were resolved: - Bump process version required for job support to 1.6.9   https://github.com/haskell/cabal/issues/6986 - GHC-8.12 is GHC-9.0   https://github.com/haskell/cabal/issues/7019 - cabal-install-head v2-install fails to process source-repository-package   https://github.com/haskell/cabal/issues/7007 cabal-install-3.4 release highlights are: - Support for upcoming GHC-9.0 - Removal of sandboxes - Improved public sublibrary support - `active-repositories` configuration - Various `cabal init` improvements - Various `cabal sdist` improvements - `source-repository-package` are not treated as local packages - Added `list-bin` command Complete release notes (drafts) are at: https://github.com/haskell/cabal/tree/master/release-notes Please do test this release and let us know if you encounter any issues: https://github.com/haskell/cabal/issues - Oleg From oleg.grenrus at iki.fi Sun Sep 27 14:18:36 2020 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sun, 27 Sep 2020 17:18:36 +0300 Subject: RFC: A plan to gradual removal of v1- commands Message-ID: Dear development aware cabal users I request you to comment on a plan to gradually remove `v1-` commands. Some users have commented about the notice in `v1-` commands' `--help`:   It is a legacy feature and will be removed in a future release of   cabal-install. Please file a bug if you cannot replicate a working v1- use   case with the nix-style commands. This note is vague, and indeed we don't have any concrete plan *when* something will be removed. Lets have one. At the moment, in upcoming `cabal-install-3.4.0.0` we have following commands:   v1-build          Compile all/specific components.   v1-configure      Prepare to build the package.   v1-repl           Open an interpreter session for the given component.   v1-run            Builds and runs an executable.   v1-test           Run all/specific tests in the test suite.   v1-bench          Run all/specific benchmarks.   v1-freeze         Freeze dependencies.   v1-haddock        Generate Haddock HTML documentation.   v1-exec           Give a command access to the sandbox package repository.   v1-update         Updates list of known packages.   v1-install        Install packages.   v1-clean          Clean up after a build.   v1-doctest        Run doctest tests.   v1-copy           Copy the files of all/specific components to install locations.   v1-register       Register this package with the compiler.   v1-reconfigure    Reconfigure the package if necessary. I propose the following plan: In 3.4.0.0 (to be officially released in a week from GHC-9.0.1 release, i.e. soon) we have already removed `v1-sdist`, as `v2-sdist` have completely subsumed the functionality, yet the interface is slightly different. In 3.6.0.0 (to be release around GHC-9.2) we will remove    - v1-update:  the v2-update should already completely subsume the functionality                  (but this have to be checked)    - v1-doctest: is a commeand which never worked properly    - v1-exec:    its description mentions sandbox package repository,                  as sandbox are already removed, v1-exec has no use In 3.8.0.0 we will remove what I'd call "interactive" development commands:    - v1-freeze    - v1-bench    - v1-reconfigure    - v1-repl    - v1-run    - v1-clean These are commands which I don't expect to be heavily used in scripts. That would leave us with what I consider essential commands. I think these are sufficient if `v1-` commands are used in some bigger build process. (Though, I'd suggest to use raw `./Setup`) This can be removed in 3.10 (or more conservatively in 3.12).    - v1-build    - v1-configure    - v1-haddock    - v1-test    - v1-install    - v1-copy    - v1-register These commands will be removed in 3.12 (skipping the 3.10). In summary:   v1-sdist          now          3.4   v1-build          two years    3.12   v1-configure      two years    3.12   v1-repl           one year     3.8   v1-run            one year     3.8   v1-test           two years    3.12   v1-bench          one year     3.8   v1-freeze         one year     3.8   v1-haddock        two years    3.12   v1-exec           6 months     3.6   v1-update         6 months     3.6   v1-install        two years    3.12   v1-clean          one year     3.8   v1-doctest        6 months     3.6   v1-copy           two years    3.12   v1-register       two years    3.12   v1-reconfigure    one year     3.8 I should mention that we don't test any of `v1-` commands anymore. The code is there, and if it works it is good, but if it doesn't, we wont actively pursue fixing it (rather concentrating on whatever issues are holding you from migration to v1-build). I would value comments whether the list for 3.6 (v1-update, v1-doctest, v1-exec) is found controversial. Very rough estimate is that 3.6 will be released early 2021, in about a half a year from now. 3.8 would happen a year from now. (Fall 2021) 3.12 where the v1-build is gone would happen in two years from now. (Fall 2022) Disclaimers: I don't want to set the plan in stone. In other words, "All rights reserved", but we would avoid removing anything earlier than agreed. Yet, it's impossible to predict the future, and we might be forced to diverge from that plan. The version numbers are informative, 3.10 could be 4.0, or the release schedule could be accelarated or slowed down. We will stick to the time based definitions. - Oleg From oleg.grenrus at iki.fi Sun Sep 27 14:20:55 2020 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sun, 27 Sep 2020 17:20:55 +0300 Subject: RFC: A plan to gradual removal of v1- commands In-Reply-To: References: Message-ID: <7aa67c5a-5892-ecc0-a192-71ef962dd0cb@iki.fi> I forgot to mention. Discussion open until the end of October 2020, that is roughly five weeks. - Oleg On 27.9.2020 17.18, Oleg Grenrus wrote: > Dear development aware cabal users > > I request you to comment on a plan to gradually remove `v1-` commands. > > Some users have commented about the notice in `v1-` commands' `--help`: > >   It is a legacy feature and will be removed in a future release of >   cabal-install. Please file a bug if you cannot replicate a working v1- use >   case with the nix-style commands. > > This note is vague, and indeed we don't have any concrete plan *when* > something will be removed. > > Lets have one. > > At the moment, in upcoming `cabal-install-3.4.0.0` we have following > commands: > >   v1-build          Compile all/specific components. >   v1-configure      Prepare to build the package. >   v1-repl           Open an interpreter session for the given component. >   v1-run            Builds and runs an executable. >   v1-test           Run all/specific tests in the test suite. >   v1-bench          Run all/specific benchmarks. >   v1-freeze         Freeze dependencies. >   v1-haddock        Generate Haddock HTML documentation. >   v1-exec           Give a command access to the sandbox package repository. >   v1-update         Updates list of known packages. >   v1-install        Install packages. >   v1-clean          Clean up after a build. >   v1-doctest        Run doctest tests. >   v1-copy           Copy the files of all/specific components to install > locations. >   v1-register       Register this package with the compiler. >   v1-reconfigure    Reconfigure the package if necessary. > > I propose the following plan: > > In 3.4.0.0 (to be officially released in a week from GHC-9.0.1 release, > i.e. soon) > we have already removed `v1-sdist`, as `v2-sdist` have completely > subsumed the > functionality, yet the interface is slightly different. > > In 3.6.0.0 (to be release around GHC-9.2) we will remove > >    - v1-update:  the v2-update should already completely subsume the > functionality >                  (but this have to be checked) >    - v1-doctest: is a commeand which never worked properly >    - v1-exec:    its description mentions sandbox package repository, >                  as sandbox are already removed, v1-exec has no use > > In 3.8.0.0 we will remove what I'd call "interactive" development > commands: > >    - v1-freeze >    - v1-bench >    - v1-reconfigure >    - v1-repl >    - v1-run >    - v1-clean > > These are commands which I don't expect to be heavily used in scripts. > > That would leave us with what I consider essential commands. > I think these are sufficient if `v1-` commands are used in some > bigger build process. (Though, I'd suggest to use raw `./Setup`) > This can be removed in 3.10 (or more conservatively in 3.12). > >    - v1-build >    - v1-configure >    - v1-haddock >    - v1-test >    - v1-install >    - v1-copy >    - v1-register > > These commands will be removed in 3.12 (skipping the 3.10). > > In summary: > >   v1-sdist          now          3.4 >   v1-build          two years    3.12 >   v1-configure      two years    3.12 >   v1-repl           one year     3.8 >   v1-run            one year     3.8 >   v1-test           two years    3.12 >   v1-bench          one year     3.8 >   v1-freeze         one year     3.8 >   v1-haddock        two years    3.12 >   v1-exec           6 months     3.6 >   v1-update         6 months     3.6 >   v1-install        two years    3.12 >   v1-clean          one year     3.8 >   v1-doctest        6 months     3.6 >   v1-copy           two years    3.12 >   v1-register       two years    3.12 >   v1-reconfigure    one year     3.8 > > I should mention that we don't test any of `v1-` commands anymore. > The code is there, and if it works it is good, but if it doesn't, > we wont actively pursue fixing it (rather concentrating on whatever > issues are holding you from migration to v1-build). > > I would value comments whether the list for 3.6 > (v1-update, v1-doctest, v1-exec) is found controversial. > Very rough estimate is that 3.6 will be released early 2021, > in about a half a year from now. > > 3.8 would happen a year from now. (Fall 2021) > 3.12 where the v1-build is gone would happen in two years from now. > (Fall 2022) > > Disclaimers: > > I don't want to set the plan in stone. > In other words, "All rights reserved", > but we would avoid removing anything earlier than agreed. > Yet, it's impossible to predict the future, > and we might be forced to diverge from that plan. > > The version numbers are informative, > 3.10 could be 4.0, or the release schedule could be accelarated or > slowed down. > We will stick to the time based definitions. > > - Oleg > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel