[enhancement] Add mininum_rebar_version and selected_rebar_version configuration

[tak30]

Pre-Check

Context: We want to be able to assure that a project is using a minimum or specific version of rebar3 by conf

Current behaviour

You need to be aware of new versions of rebar3 in order to check if your project is still working as expected

Expected behaviour

You will be able to configure either a mininum_rebar_version or a selected_rebar_version. If your current rebar3 does not comply with the minimum or selected then we have two options:

• Fail
• Automatically download that specific version needed and use it

[paulo-ferraz-oliveira]

@tak30, just a heads up: it will (might?) not be available for previous rebar3 versions unless the maintainers make it so. So if I'm running 3.12 and you expect 3.19+ there'll be no warning (as the version recognition mechanism is not known in past versions). Though I agree such mechanism would be useful, we (because of backward compatibility) ended up wrapping our rebar3 calls in a Makefile our lib.s share, so that this type of behaviour is readily available.

[tak30]

@paulo-ferraz-oliveira that is a good point but I believe it is worth to add it anyway, it will be useful soon enough I believe :)

Another workaround is having the rebar3 binary in the project and I've seen that but it hurts my heart :D

[paulo-ferraz-oliveira]

Yeah, I've seen rebar3 in projects way too many times, and feel the same as you do. 🤣

You are right, though: it might be helpful, "from here on out," I was just pointing to the fact that it might not be backwards compatible (I only remember one time when previous versions were patched and re-released and that was for security reasons - though there might've been other times).

[ferd]

Another gotcha here is that setting this mechanism means that you may end up with an unbuildable project if two dependencies set mutually incompatible versions despite many of them being compatible. The moment this happens and the versions are checked for deps, then the project can't update deps anymore (because it bails out ASAP).

Specifically for selected_rebar_version, this sounds like a bigger source of problems than an actual thing that would be helpful. Minimum versions are probably okay and may act as a nag to push people to update, but yeah.

[tak30]

That is true, one thing that could be possible is to use the selected_rebar_version of the main rebar.config (parent project) and don't pay attention to that conf for the dependencies. I believe this conf is only useful for projects that have releases, libraries shouldn't use it and instead use the minimum_rebar_version conf.

With the minimum_rebar_version is different, I'd say check also the dependencies.

What do you think?

[ferd]

I think it should be possible. I think a minimum_rebar_version config that is only read at the top-level could make sense. I still don't think that a selected_rebar_version argument is a good idea because it messes with things like security patches and whatnot.

[tak30]

Regarding selected_rebar_version: What we are trying to fix is the need for creating Makefiles that only enforce an specifc version of rebar or even adding the rebar3 binary into the repository and using that binary.

Some projects are using it in order to avoid breaking the CI pipeline because of a new version of rebar3 is published.

One could argue that the CI base "image" should configure that specific version of rebar but if you have a team of developers working on the same project it is nice to ensure all of them are using the same rebar3 version.

[paulo-ferraz-oliveira]

if you have a team of developers working on the same project it is nice to ensure all of them are using the same rebar3 version

Just throwing something out there: did you try creating a team-wide policy for this (i.e. bump rebar3 everynow and then?)? Would it not work? Especially if you're all working on "latest" rebar3, updating is as easy as rebar3 local upgrade.

[ferd]

Some projects are using it in order to avoid breaking the CI pipeline because of a new version of rebar3 is published.

Your pipeline will break every time a new version will be published still by doing that, it will just tell you it's because there's a new version though.

Dependencies are sort of a nightmare to have this work properly, but top-level umbrella projects (which build and publish a final top-level release) are probably fine to vendor a rebar3 into, because it won't be re-fetched by dependencies at a later point.

In all cases (vendoring, CI, selected_rebar_version), you'll have a coordination issue of ensuring all versions are compliant across all builds when maintaining your own dependencies in multiple repositories. To mandate a unique rebar3 version across all subprojects, you'd probably have to lean on CI and to a central URL from which you fetch the globally selected rebar3 so all builds for all repos get the same executable regardless of their local configuration.

I can understand wanting a clearer error than an obscure failure when you suspect the version is to blame for the problem, but my guess is that you'll have more failures due to mismatches in rebar3 versions even when there are no breaking behaviours than you'll have due to breaking behaviors themselves.

[tak30]

Yep, you are totally right. On my trying of getting rid of those rebar3 binaries in repos I didn't consider everything. Thanks for the explanation!