0.12.1.1 breaking change w.r.t. 0.12.0.3

[jkachmar]

It looks as if vector-0.12.1.1 has renamed the Vector.Generic.mkType function to Vector.Generic.mkVecType.

cf. mkType @ 0.12.0.3 versus mkVecType @ 0.12.1.1

[lehins]

Not sure what was the motivation behind this change, but the proper way to fix this issue I see is bring back mkType as deprecated:

mkType :: String -> DataType
{-# INLINE mkType #-}
{-# DEPRECATED mkType "In favor of mkVectType" #-}
mkType = mkNoRepType

and make new release vector-0.12.1.2, while deprecating vector-0.12.1.0 and vector-0.12.1.1

@cartazio Would you be keen to making such release if I fix it in proposed way?

[cartazio]

Absolutely I did have an “oh no moment” late last night when I remembered that the data instance had existed but was so useless that I was used to treating it as not existing. So indeed I can do that post haste. Email / msg me or holler on a ticket when you think it’s in a good shape. Or I can do a thing. Was pointed out to me that currently we don’t have terribly good test coverage atm wrt hpc coverage metrics (granted we couldn’t even run the optimized test suite till last week :) @hvr @davean is https://hackage.haskell.org/package/hackage-diff The tool you two have used for doing api diffs? Or was it a different one? Probably would be good to add to release engineering workflow / checklist (which we don’t have quite yet ;))

…

On Sat, Feb 1, 2020 at 1:03 PM Alexey Kuleshevich ***@***.***> wrote: Not sure what was the motivation behind this change, but the proper way to fix this issue I see is bring back mkType as deprecated: mkType :: String -> DataType {-# INLINE mkType #-} {-# DEPRECATED mkType "In favor of mkVectType" #-} mkType = mkNoRepType and make new release vector-0.12.1.3, while deprecating vector-0.12.1.1 and vector-0.12.1.2 @cartazio <https://github.com/cartazio> Would you be keen to making such release if I fix it in proposed way? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#287?email_source=notifications&email_token=AAABBQQZABUCLHPHFQZBBFTRAW2QZA5CNFSM4KOUPBK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKRC6RA#issuecomment-581054276>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQSRXFPNDHGMQHTBP4LRAW2QZANCNFSM4KOUPBKQ> .

[lehins]

The fix is ready: #288

The tool you two have used for doing api diffs?

There was recently an announcement of policemen that could potentially help with that. Have not used it though, so can't vouch for it.
https://www.reddit.com/r/haskell/comments/ew1vd5/blog_post_policeman_new_way_to_assign_pvp/

[chessai]

@lehins unfortunately per PVP depreciation entails a majour version bump. So maybe that isn't the right choice? Unsure.

[lehins]

PVP should have been fixed long time ago: haskell/pvp/issues/12

But thats fine, I'll make a fix without DEPRECATE pragma.

[chessai]

@lehins i personally agree. Hopefully it will be updated soon. Unfortunately for now, we must adhere

[lehins]

@chessai I would not have my hopes up, it's been 3 years since that linked issue on pvp

[jkachmar]

Unfortunately for now, we must adhere

Must we?

[cartazio]

FIXED