Set version in committed mix.exs

[halostatue]

The current application version is set as @version "0.0.0" in mix.exs. Ideally, this should be set to the current (or next) version in the source branch so that a dependency can be specified as:

{:file_store, "~> 0.2", github: "rzane/file_store", branch: "master"}

As it is, we cannot specify the version as anything other than >= 0.0.0 if using a git branch.

[rzane]

Ahh, yeah, that's pretty annoying. The reason it's set to 0.0.0 is because I have a GitHub action that automates the release whenever a new GitHub release is created.

Is there any reason why >= 0.0.0 is a bad thing when using a GitHub source?

[halostatue]

It allows git dependencies to be combined with version dependencies.

If I specify this {:file_store, ">= 0.0.0", github: "rzane/file_store", branch: "master"}, then when 1.0 or 2.0 comes out, a mix deps.update file_store will happily move me to that version. On the other hand, {:file_store, "~> 0.2", github: "rzane/file_store", branch: "master"} will refuse to update to that version because it doesn’t fit within the specified version range.

I could always use a tag or a specific commit instead of master, but unless you have something like a v0.x tag that you move with each increment on release (this is what I do with my fish plugins)…there’s not much that can be done to give me the same flexibility as what I have here.

I haven’t done a lot of releases of packages in the Elixir world, but when I release Ruby gems, I use hoe which:

1. Requires that I update the version in a commit prior to release and have a clean tree.
2. Requires that I specify the version that I’m releasing (rake release VERSION=1.2.3) which helps prevent d’oh moments.
3. Releases the package to RubyGems.
4. Tags my git repo with the version (effectively making a release).

It makes package release a bit more manual, but I like that last little bit of verification. This could probably be automated with actions a little differently for what you’re doing:

1. Make a commit that just updates the version and has a specific commit message (Release 1.2.3) on the main branch.
2. The action looks for that commit by a collaborator and creates a release.
3. The action then releases the package with the version specified.