lortabac / versioning Goto Github PK

We should provide a way to upgrade effectfully. The use cases that come to my mind are reading the default values from a database, keeping some state or logging/monitoring.

I am not sure what the best way is to add this functionality. The simplest solution would be to add a new UpgradeM module and let the users choose between pure and monadic upgrading by importing the module they need. The downside is that it would become possible to define instances for both upgrading modes, which may be a bad idea.

Unfortunately I was not able to find a way to unify the interface without making pure upgrading more cumbersome.

The short tutorial in the README should be included as Haddock documentation in versioning.cabal.

Exclude buggy minor GHC versions, include the most recent versions, evaluate alternatives to Travis.

Sometimes the Adapt instances are completely mechanical. For example all the fields whose type did not change are just copied, new Maybe fields are set to Nothing, new strings are set to "", etc.

It would be nice to provide some tools to reduce boilerplate with Generic. The generic functions should be configurable by type and by field (see generic-random for inspiration).

Currently the decoding functions like fromJsonAnyVersion work by trying to decode at each version until the first one succeeds. This is convenient as a default strategy because of its simplicity.
However a better solution would be to rely on an explicit versionNumber field and decode to the target version directly. The implementation will probably require the SV singleton type (currently only on the singletons branch).

The tar.gz file uploaded to hackage seems to be missing the Versioning.Servant file.

Versioning requires bytestring <0.11:

GHC 9.2 ships with bytestring version 0.11. It would be great if versioning could support the most recent versions of GHC.