search

rzane / file_store

🗄️ A unified interface for file storage backends
MIT License
19 stars 3 forks source link

Set version in committed `mix.exs` #24

Open halostatue opened 3 years ago

halostatue commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.