I wanted to try out a workflow where updates to the package be bumped and published automatically on a PR merge. However, this is my first package and I’m a bit unsure what commands could be useful.
The general idea is that I have a dev branch and whenever I want to publish a new version, I simply merge a PR into master. The CI would then run all tests and if everything went right, it would bump the package’s version and publish it.
Alternatively, I could manually bump the version on dev right before merge. But with Elm’s auto-detection of the version diff, I was wondering how much could be automated.
The only issue I see is that one might accidentally publish a major version, simply because they forgot that they deleted a function. So there maybe should be some sort of feedback loop before the CI publishes a major version.
What do you think of this? What commands could I use (on travis)? What upsides and pitfalls do you see?
I think that having a human review with elm diff is really important. It has caught mistakes in a bunch of cases in my experience.
So it may be possible to save yourself a minute, the risk is that all the users of your package may end up paying a time cost. I think that is not a good trade for the ecosystem overall.
I also think that packages should generally not be getting updates super often. That has costs for the people using the package, so if I saw a package that updates so frequently it is worthwhile to automate it, I would be worried for other reasons.
I also think that packages should generally not be getting updates super often. That has costs for the people using the package…
That’s been my experience as well, it is really valuable to let a human choose when to increment the package version. Releasing automatically would give me a lot of unwanted releases in the packages that I maintain. And I like to review my changes to make sure the docs, the API changes, and the changelog entry are looking good before I push a release out there.
It might be helpful to look at parallels in other ecosystems. I actually just configured a Travis job to automatically publish an NPM package earlier today. It does a release every time I increment and tag a new version (it happens to be an NPM package that accompanies an Elm package). That gives me control over when I release and let’s me review things, but it automates the tedious parts.
I find this handy because it runs my test suite in my CI environment as a sanity check before publishing. And in the case of NPM, it transpiles the code for the NPM binary (I don’t think there would be anything like that needed for an Elm package, though).
Anyway, I hope that context is helpful! You can do custom deploy scripts using Travis, so you could set something similar up I think for an Elm package. Here’s the relevant documentation: