Erlang Solutions downloads and versioning for Elixir

General Prog (Archived)
1

I would like to understand why the Erlang Solutions download page have the same Elixir version twice?

Example:

Screenshot%20from%202019-05-15%2009-19-59

I notice the same happens for Erlang releases.

2

The -2 is probably a build that has been tweaked somehow. For example, they may have flipped some build flag and decided to rebuild the package, but since immutability is good and you should not re-upload changed version with the same version number, they upload another one with -2, -3, -4 etc. if they need to make these sort of tweaks. You probably should grab the most recent build.

4 Likes
3

I though that was to solve some bug with the previous released build… So I was not to far :wink:

Anyway their use of -2 for that is weird and not consistent acrross all releases they build.

In my opinion I would prefer to see a build number being used explicitly in all releases they build:

  • 1.8.0-build:1234
  • 1.8.1-build:1235
  • 1.8.1-build:1236 aka the 1.8.1-2
4

Packages for Arch Linux use this approach too, it makes sense because it’s not a change in the software itself, i.e. it receives an update, instead is just a hotfix to patch errors with the installation, build, etc… for example:

elixir 1.2.4-1: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/elixir&id=d0ee50e01108cad3db888a3d8c6c5464146d6ee8

elixir 1.2.4-2: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/elixir&id=a8a4ccf87975aeb22df4d984cdc3fa59520d9b89

Notice the change in the dependency from erlang to erlang-nox.

1 Like
5

This is not necessarily compatible with the versioning schema of the package manager used.

1 Like
6

Tell me about :wink:

I am building an Elixir Docker Stack and I am resorting to a map in order to fix the inconsistencies in the versioning.

For Erlang:

erlang:21.3.....esl:21.3.8
erlang:21.3.0...esl:21.3
erlang:21.3.7...esl:21.3.7.1

erlang:21.2.....esl:21.2.7
erlang:21.2.0...esl:21.2

erlang:21.1.....esl:21.1.4
erlang:21.1.0...esl:21.1

erlang:21.0.....esl:21.0.5
erlang:21.0.0...esl:21.0

erlang:20.3.....esl:20.3.8.21
erlang:20.3.0...esl:20.3
erlang:20.3.2...esl:20.3.2.1
erlang:20.3.8...esl:20.3.8.21

erlang:20.2.....esl:20.2.2
erlang:20.2.0...esl:20.2.0.1

erlang:20.1.....esl:20.1.7
erlang:20.1.0...esl:20.1

erlang:20.0.0...esl:20.0

erlang:19.3.....esl:19.3.6.13
erlang:19.3.0...esl:19.3
erlang:19.3.6...esl:19.3.6.13

erlang:19.2.....esl:19.2.3
erlang:19.2.0...esl:19.2

erlang:19.1.....esl:19.1.5
erlang:19.1.0...esl:19.1

erlang:19.0.....esl:19.0.7
erlang:19.0.0...esl:19.0

erlang:18.3.....esl:18.3.4.11
erlang:18.3.0...esl:18.3
erlang:18.3.4...esl:18.3.4.11

erlang:18.2.0...esl:18.2

erlang:18.1.0...esl:18.1

erlang:18.0.0...esl:18.0

erlang:17.5.....esl:17.5.3
erlang:17.5.0...esl:17.5

erlang:17.4.0...esl:17.4

erlang:17.3.0...esl:17.3

erlang:17.1.0...esl:17.1

erlang:17.0.0...esl:17.0

For Elixir:

elixir:1.8.......esl:1.8.2-1
elixir:1.8.1.....esl:1.8.1-2

elixir:1.7.......esl:1.7.4-1

elixir:1.6.......esl:1.6.6-2
elixir:1.6.6.....esl:1.6.6-2

elixir:1.5.......esl:1.5.2-1

elixir:1.4.......esl:1.4.5-1

elixir:1.3.......esl:1.3.4-1

elixir:1.2.......esl:1.2.6-1

elixir:1.1.......esl:1.1.1-2
elixir:1.1.1.....esl:1.1.1-2

elixir:1.0.......esl:1.0.4-1
elixir:1.0.3.....esl:1.0.3-2
7

Sorry but it does not make sense to me… from my point of view is inconsistent in the version schema used or whatsoever you want to call it :wink:

I understand what causes the changes from one release to the other, but in my head I cannot make sense of the way chosen to reflect them… maybe is only my old brain :wink:

8

Sorry, but I have no clue what you want to tell with that table… There is no elixir 1.6. there is always a major, always a major and always a patch in the version, never major and minor only.

9

Well, it’s just a number describing the version of the package build instructions if you want to say.

In case of Haskell packages they are also abused for other things and might become astronomically high very fast, but abusing them that way is the exception, not the rule.

The Haskell stuff is specific to pacman though, emerge found a slightly different way to deal with the same problem, while other package repositories completely ignore the problem or even circumvent it by not distributing Haskell packages.

But all package managers have the same concept of 2 version numbers, one for the content of the package and one for the build instructions where the latter usually is just a monotonically increasing number which gets reset when the version of the contents changes.

Some managers imply that a missing version is the first, some need it explicitly.

1 Like
10

erlang:21.3.7 means the semantic version requested in the Docker Stack, while esl:21.3.7.1 is the Erlang Solutions version that corresponds to it.

So the versions in the map are only the ones that need to be fixed in order to comply with the way Erlang Solutions uses in their download page.

I hope that it makes sense now.

11

Docker tags do not need to point to a certain package on ESL, sometimes they are even build from source or installed from prebuilt tarballs or similar.

Also those tags might change the corresponding fully specified version without any notice. The tag elixir:1.6 just tells you that you’ll get any 1.6.x.

Docker is not producing a fully reproducible environment when using named tags.

12

I should not have mentioned the Elixir Docker Stack I am building because now all of you are missing the context that is only in my head…

This Elixir Docker Stack will have tags that build on top of Elixir and Erlang from:

  • Erlang Solutions.
  • Git repos.
  • Official Docker Hub Images.

Phoenix will be installed from:

  • Hex
  • Git repo

The goal is to be able to run Elixir, Erlang and Phoenix in Docker with them being compiled from our preferred source.

So in the end we will be able to live in the bleeding edge and try the last branch of master for Erlang, Elixir and Phoenix with a throw away Docker Container.

Yes I know this :slight_smile:

When I am pointing elixir:1.6.......esl:1.6.6-2 you can see that 1.6.6-2 is the last release that Erlang Solutions have for Elixir 1.6.x, thus I am following the Docker way.

13

Sounds complicated… I tend to stick to asdf or a properly set up VM.

14

I am used to use Docker for everything in the last 3 years, and I can’t live without using Docker in my development workflow… is just much cleaner that anything else, and as a result my operating system almost doesn’t have any developer tools installed, Docker all the way I can :wink:

The most complicated thing here is to get the Erlang Solutions versioning sorted out to Docker tags, the rest is just more easy.

15

I do use docker for many things as well (better: containers), but not to “play with something new”.

A VM which I can provision using ansible or puppet or any other tool that my ops team considers appropriate to have something close to a customers environment. Also Snapshotting and rolling back and forth to intermediate states is easy if done right.

I never had this experience with docker.

Docker shines in my workflow for testing in pristine environments or when doing releases. About 95% of the things I develop are targetting some container to run in. But because of this I’m also using about always alpine or even scratch containers. I rarely use Ubuntu or RedHat based images. Not even the slim ones…

1 Like
16

I use for playing around with stuff and for professional development.

This is where Docker shines, just build the docker image using the digest on the tag and push it to a private registry, and you can afterward switch back and forth between immutable docker images.

Trying to recreate the same immutable docker image from a Dockerfile will not work because we may get newer versions of software when running apt install some-package.

1 Like