I have some more thoughts on this!
When the release candidate of the compiler came out, several core libraries opened
compiler/0.12 branches, and by the time the official release occurred the majority of core libraries were already ready to go (like
purescript-prelude, etc.). However, unless I missed something major, there wasn’t much of a push to notify the rest of library authors about the release candidate, nor did the release candidate last very long.
To date, there are still pull requests trickling in to libraries like
purescript-remotedata, and so on which are relied upon by at least meaningful bits of the ecosystem.
This seems unavoidable: we can’t force anyone to update, and if they aren’t tuned in on Slack or Discourse or Reddit then they’ll simply miss the new release, and won’t update until someone opens an issue or a pull request on their repository.
However, perhaps we could do something more. We could at least make a good faith effort to notify people who maintain repositories available on Pursuit if their code is going to break in the new release. Perhaps we could do something like this:
- Aggregate the packages on Pursuit, and their GitHub URLs
- For each, make a simple check for breaking changes in the new compiler (still using
identity, still importing
Control.Monad.Aff instead of
- For packages that will break, delegate to a small team to make the final decision as to whether the library author should be notified (perhaps there are some circumstances where our simple check will be incorrect) – I volunteer for this team, for starters.
- For each package that will break, that team can open an issue on the repository stating “There is a new version of the compiler coming out that will break your code. Here is the release candidate. Here is a summary of changes in the compiler. In 3 weeks, the compiler will come out and the ecosystem will need to upgrade.”
With this process ^^ it still makes sense to update core libraries first and anything that core contributors have access to in order to minimize the number of blockers preventing library authors from updating (from their further dependencies). Perhaps we could follow a similar process for that:
- Aggregate from Pursuit all packages + their dependencies
- Rank libraries in order of the number of dependent packages on Pursuit (as we don’t have access to application code, and can’t judge dependents that way)
- Ensure some threshold of core libraries are updated before the next process starts (release candidate + notify authors with GitHub issues)
Finally, there could be a “documentation team” which I also volunteer for:
- For core libraries, we might need to update documentation when things have changed
- If there is an accompanying ecosystem change, like the
purescript-avar changes, then there ought to be an accompanying official blog post that summarizes the changes, why, and where to find the new packages
- I think the team did a great job moving libraries to
purescript-deprecated and updating READMEs. It’s unfortunate these did not get pushed to Pursuit and that still ought to be fixed. It’s the right idea.
- There should also be a ‘migration guide’ that details a) What processes are being done to upgrade everything; and b) some tips as a library author for migrating.
I think we can learn from this compiler update and put together processes to be better next time. And the same processes can work if there’s a major library update, in which the compiler remains the same but we realize we need a re-organization in things like the
As I noted in a few places: I believe it’s crucial that new users are able to come to PureScript within 30 days of a compiler release and have things working, and equally that commercial users are able to feel comfortable that new releases will resolve themselves reasonably quickly. I understand there are challenges to this, PureScript is a relatively new and niche language, and anyone using it should expect breaking changes and to have to figure things out from time to time.
But these challenges don’t seem too formidable, and that gives me confidence we can resolve them and provide a better experience for new and existing users during a transition.