Next release, 0.8

[meooow25]

It's been a while since 0.7 and we've accumulated commits, should we start preparing for a release?

Pending things I'd like to see done/fixed for 0.8:

• Add filterKeys for Map and IntMap #972
• NFData1,NFData2 instances (#767) #992
• updateMax Map/IntMap discrepancy #1061
• foldl' and foldr' for Seq are not strict in the starting value #1072
• Improve Ord instances for IntSet and IntMap #470, Improve Ord IntSet instance #787
• IntSet foldl and foldr smell funny #666
• Inline the common case of balance functions #1056
• Improve fromAscList and friends for Set and Map  #1083
• Build Set and Map more efficiently and consistently #1042

[Bodigrim]

It's expensive to bump major version of containers, hundreds and thousands of packages would have to update. Please consider sticking to 0.7.*.

There is an upcoming release of GHC 9.12 very shortly, do you aim to release containers before that? As with any boot library, clients hardly ever use a release unless it is bundled with GHC.

[meooow25]

It's expensive to bump major version of containers, hundreds and thousands of packages would have to update. Please consider sticking to 0.7.*.

We have breaking changes so we do need a major version bump. The changes aren't drastic (at least in the public API), but they are still breaking changes.

There is an upcoming release of GHC 9.12 very shortly, do you aim to release containers before that? As with any boot library, clients hardly ever use a release unless it is bundled with GHC.

GHC 9.12 is sticking to 0.7 (GHC #25123), which is fine.

---

Anyway, the release is not happening right now. This is just to get the ball rolling and track what we want to include, we can decide the time of release once these issues are resolved.

[flip111]

GHC 9.12 is sticking to 0.7

I'm not sure but i have the feeling they put that version number there because it was the latest version available. Perhaps it would be nice to have a new containers version together with a new major ghc versions because at that point several things have to be upgraded anyway. Though i can understand it would perhaps be too short notice. Would it go into ghc 9.14 then? or a point release of 9.12?

[treeowl]

I don't think a point release is likely to take a major release of containers. If we want to get a major release in, now is probably the last time.

[meooow25]

Yes, 0.8 should make it into 9.14.

Even if it's not too late for 9.12, I don't see a good reason to rush the release. A new major release means other core libraries also need to update to accept the new containers, which is a lot of work. Another thing I want to make sure is that we include all the breaking changes we want to at once, so we don't need another major release in the near future.

[meooow25]

We're done with the checklist, so I'm thinking we can make the release at the end of this month. I'll take a look at the open issues to see if there's anything else that would be nice to include.

@treeowl does that sound alright to you?

[treeowl]

Sounds reasonable, yeah. My work on GADTy sequence stuff won't be ready in time.

[Bodigrim]

I'd suggest to try and bump container submodule in GHC source tree before cutting a release. Ideally with user-facing label to trigger head.hackage CI job.

[meooow25]

From the head.hackage run (GHC !13989):

4 packages failed to build:
    Agda 2.7.0.1
    arithmoi 0.13.0.0
    rio 0.1.22.0
    strict-containers 0.2
0 packages failed to build (expected):
    
4 target packages failed to build:
    Agda 2.7.0.1
    aura 3.2.9
    cryptol 3.1.0
    strict-containers 0.2
9 packages failed to build due to unbuildable dependencies.

Agda fails because it defines its own filterKeys.

src/full/Agda/Syntax/Scope/Base.hs:782:56: error: [GHC-87543]
    Ambiguous occurrence ‘Map.filterKeys’.
    It could refer to
       either ‘Map.filterKeys’,
              imported qualified from ‘Data.Map’ at src/full/Agda/Syntax/Scope/Base.hs:17:1-32
              (and originally defined in ‘Data.Map.Internal’),
           or ‘Map.filterKeys’,
              imported qualified from ‘Agda.Utils.Map’ at src/full/Agda/Syntax/Scope/Base.hs:49:1-38
              (and originally defined at src/full/Agda/Utils/Map.hs:58:1-10).

rio fails because it re-exports the erroring functions which are now gone.

src/RIO/Map.hs:184:5: error: [GHC-76037]
    Not in scope: ‘Data.Map.Strict.showTree’
    Note: The module ‘Data.Map.Strict’ does not export ‘showTree’.
    ...

arithmoi fails because it imports the removed BitUtil. But it only uses it to define a symmetric difference operation, which we now have.

Math/NumberTheory/Primes/IntSet.hs:90:1: error: [GHC-87110]
    Could not load module ‘Utils.Containers.Internal.BitUtil’.
    it is a hidden module in the package ‘containers-0.7’

strict-containers fails because it imports Key.

src/Data/Strict/IntMap/Autogen/Internal.hs:311:30: error: [GHC-61689]
    Module ‘Data.IntSet.Internal’ does not export ‘Key’.

The last one seems to be unnecessary trouble. Though this package seems to be auto-generated from containers, so maybe it's not a problem. Anyway, I think there is no strong reason to remove Key from the internal module exports, so I will add that back.

The rest of the errors are expected.

[Bodigrim]

9 packages failed to build due to unbuildable dependencies.

It would be nice to check whether these 9 packages can be built once their dependencies are patched.

[meooow25]

That sounds like a lot of work and the answer will surely be yes. Do you expect to find anything in particular?

[Bodigrim]

Up to you, I'm slightly worried that rio failure might hide issues in downstream packages.

Happy to make a new release of arithmoi ahead of time, if it helps.

Speaking from experience of dealing with GHC boot libraries, any compatibility testing you do upfront saves a ton of time and frustration later on.

[meooow25]

Sorry, I don't understand your concern about issues in downstream packages.

This will be a major release. When the maintainers of these packages want to allow 0.8, they will see the changelog and update their code if they need to. Most likely they will not need to do anything. If that's not the case, they might need to resolve naming conflicts or use a function that's not deprecated/removed. There is nothing out of the ordinary here.