Please clarify relation between data-default and data-default-class

[thielema]

I see you released data-default-0.8.0.0 yesterday. It does no longer re-export Default class from data-default-class. This is a breaking change, indeed the major version bump to 0.8 indicates that.
For instance, package hledger-web imports data-default and yesod, where yesod defines instances for data-default-class. hledger assumes that Default class from data-default and data-default-class are actually the same.
Could you clarify which package, data-default or data-default-class, shall be preferred in the future? Will data-default-class become deprecated or what will the relation between the two packages be? Changelog or Release Notes would be nice.

[mauke]

Re: Changelog, see https://github.com/mauke/data-default/blob/ba1596728252c8f640d21225e728f508f2f3233c/Changes.pod#user-content-pod0.8.0.0.

The plan (starting from 0.8) is to return back to a single data-default package (like before 0.5.2).

data-default-class is not formally deprecated, but effectively requires you to stay with data-default >=0.5.2 && <0.8 because the two packages don't work together otherwise.

[sol]

@mauke It will cause less friction for the ecosystem if you upload a new version of data-default-class that re-exports data-default (0.8.0).

[mauke]

@sol I've been wondering about that. As far as I can see, there are three options:

1. I do nothing.

   People can still write code compatible with either data-default or data-default-class by doing something like (untested):

   flag use-data-default
   ...
     if flag(use-data-default)
       build-depends: data-default ^>=0.8
     else
       build-depends: data-default-class ^>=0.1.2.2
   

   {-# LANGUAGE CPP #-}
   #if defined(MIN_VERSION_data_default_class)
   import Data.Default.Class
   #else
   import Data.Default
   #endif

   Pros: I don't have to do anything.
   Cons: Requires annoying compatibility checks from each user, plus CPP hacks.

2. I do nothing.

   People can still write code compatible with both versions of data-default by doing something like this:

     build-depends: data-default >=0.7 && <0.9
   

   import Data.Default

   Pros: I don't have to do anything.
   Cons: Manual action required from anyone currently using Data.Default.Class (they have to switch to Data.Default instead). With older versions of data-default, this pulls in extra package dependencies (dlist, old-locale).

3. I upload a dummy data-default-class that just re-exports Data.Default.

   This will be a new major version because instances were removed, so people depending on data-default-class will have to relax their version bounds:

     build-depends: data-default-class >=0.1 && <0.3
   

   Pros: In many cases where import Data.Default.Class is currently used, the Haskell code won't have to be touched at all.
   Cons: I have to do something. :-) And people still need to change their cabal files, so manual action is still required of them.

Do you think option 3 saves enough maintainer effort over 2 that it's worth it?

[sol]

Do you think option 3 saves enough maintainer effort over 2 that it's worth it?

Yes.

[mauke]

I've uploaded a package candidate: https://hackage.haskell.org/package/data-default-class-0.2.0.0/candidate

Does this look reasonable to you?

Disregard that, I've published https://hackage.haskell.org/package/data-default-class-0.2.0.0.