Fantasy Land specification version number

[Avaq]

This repository contains two things:

1. The Fantasy Land specification
2. The source for the fantasy-land package on npm

Currently, both are subjected to the same version number: the one specified in package.json. Over the lifetime of Fantasy Land, the "major" part of this version number has been bumped whenever a breaking change in the specification occurred (the prefixing of method names, the flipping ap, etc). The major version of "Fantasy Land" has therefore always been a decent indication of what libraries are compatible with one another, and so a good means of communication and disambiguation.

With the latest major version bump, the breaking changes did not apply to the specification itself, but to the npm package. This means that all libraries conforming to Fantasy Land 3, also conform to "Fantasy Land 4". I think this might become a source of confusion.

Perhaps - if others agree that this issue needs solving, - instead of relying on the package version number for communicating the version of the specification, we could embed a formal version number in the specification document. Or alternatively, perhaps the npm package source code could be moved into its own, separately versioned, repository.

[davidchambers]

v1.0.0 was released 900 days ago; v4.0.0 was released yesterday. 300 or so days per major release.

v2.0.0 and v3.0.0 both included breaking changes to the specification, making v4.0.0 an anomaly.

When we add a type class to the specification, we also want to update index.js and index.d.ts. Were these files to live in another repository we would need to submit and merge a pull request here, then publish this “package”, then submit and merge a pull request there, then publish that package.

Now that the fantasy-land package comprises only a trivial JavaScript file, a trivial TypeScript file, a licence file, and a readme, I find it hard to imagine another change which would necessitate a major release without any breaking changes to the specification. Can you think of one?

Even if we publish an “unnecessary” major release every few years, library authors can simply update their documentation to refer to the new version. The existence of ADT libraries which are compatible with versions n and n − 1 of the specification simultaneously is less confusing than having two related packages with different version numbers.

Finally, I argue that we shouldn't refer to “Fantasy Land 3” when describing compatibility. Does this mean 3.0, 3.1, 3.2, 3.3, 3.4, or 3.5? We should make this clear. If we do so, major releases are no more disruptive than minor releases as far as the documentation of ADT libraries is concerned.