How to use Git tags with semantic versioning in mix.exs?

Background

We have a private repository in git that uses tags. In our mix.exs we have the following:

  defp deps do
    [
      { :plug,    "~> 1.0"  },
      { :my_repo, git: "git@github.com:my_company/my_repo.git", tag: "1.0.0"  }
    ]
  end

Now if I only want version 1.0.0 from :my_repo that’s fine.
However what happens if I want any version compatible with 1.0.0? The original documentation doesn’t seem to have an options flag for this:

https://hexdocs.pm/mix/Mix.Tasks.Deps.html

Problem

This is what is happening in { :plug, "~> 1.0" },. Here I say “give any 1.X version compatible with this one”.

I want the same thing for git repos. After checking the git docs, I know this is possible using the -l command:

https://git-scm.com/book/en/v2/Git-Basics-Tagging

git tag -l "1.8.5*" would return all versions compatible with 1.8.5.

Questions

  1. Is there a way to pass the -l option to the mix.exs deps function?
  2. If not, what other options do I have?
1 Like

A tag is a direct Pin. You can not change that. You have to use branches instead, but thats a lot of overhead in terms of housekeeping the branches, especially if you want to maintain them roughly semver compatible for all three parts of the version.

Perhaps you can use a private hex repo? On a quick search I found this thread:

Also there is mix hex.repo to manage repositories.

2 Likes

@NobbZ
Another recommended solution was to make a PR with this feature to the mix team.

What are your opinions on this? DO you think it would be feasible / welcome?

1.3.5* as a tag specifier can not be expressed in terms of a mix version specifier. It would include 1.3.5-rc0 which is smaller in version than 1.3.5, but it would include 1.3.5.1 which is not even a valid version. Which of those would you choose as the most recent?

1.3.5* as a tag specifier would not include 1.3.6 which would be totally compatible to 1.3.5 but may contain bugfixes.

1.3.5* as a tag specifier will then contain 1.3.50, so after years of your application was stale, builds will happen to do unexpected stuff and fetching libraries which should be compatible, but god knows what happens after 45 patch releases!

I do not consider it a solution to your problem and stick to my advice of either using branches or using a private hex repository.