Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Add support for minimum OTP versions #243

wants to merge 1 commit into from

6 participants


Since you can't really do math with regexps and it's a pain to
repeatedly update the config for each new version of erlang, I
added support for minium OTP versions. This change is needed
to make basho/riaknostic#38 fixable.

It's possible that this will need to be extended. As an example:
Your program requires a feature that was added in R13B01, but
version R14B02 has a bug that causes your program not to work

You could implement this in terms of the existing requirements,
but you might want something like bad_vsn or max_vsn to make
it more explicit.

@evanmcc evanmcc Add support for minimum OTP versions.
Since you can't really do math with regexps and it's a pain to
repeatedly update the config for each new version or erlang, I wanted
to add support for minium OTP versions.  This is a fix for

TLDR; min_otp_version covers 99% of the use case without adding undo complexity for the project owner or his users, though I would like to see it called something like "greater than or equal".

The long version. You don't want project owners specifying close constraints on the otp version in any case. Doing that vastly complicates the life of the project owner as well as people that try to use that project. Its much better for everyone if they specify something like a min version (for when backwards compatibility breaks) and just keep the project up to date on the latest. If thats not happening the project is dead anyway.


Eric, that was my feeling. I think that the feature works OK as added. Do you have an idea for what the atom would look like for greater than or equal?


I actually think you can just go with min. One is just as good as the other and they both have the same meaning. At this level it just comes down to personal preference :)


@tuncer does this PR need any further changes or can it be merged?


The implementation of require_min_otp_vsn looks good.

@dizzyd @joewilliams are we in agreement that
1. there's no special meaning if both require_otp_vsn and require_min_otp_vsn are specified
2. require_min_otp_vsn is enough and we don't want/need bad_vsn, max_vsn, or a constraint solver


@tuncer I think that sums it up correctly. Where 2. has the caveat (at least for now).


Version resolution could be combined with #263, which implements semantic versioning.

Though it should be extended for OTP versioning (R15B does not really fit x.y.z convention).

@tuncer tuncer was assigned

@evanmcc @Motiejus The OTP versioning could match the ERTS version instead, which is incremented in a more traditional fashion than the OTP release name.


I like this patch, except for the fact that it introduces yet another way to check the OTP version. Really, the only way I've seen OTP version checking used has been as a minimum -- perhaps this should be the default?


Right now the only thing that has been implemented is as a minimum, all of the other commentary has been speculative.

Regarding the yet another way comment, is there a canonical way to get the OTP release information from within erlang? I figured the use of regular expressions in the rest of the module indicated that there wasn't one.


@evanmcc There is no real way to tie the OTP version to an actual erts release unfortunately. That means you end up having to using the OTP version itself and its just a string that doesn't act very much like a decent version. (I hope I understand what you are saying). I guess you could do something like turn the version into a number (R15B01 to 15.01) and treat it like a version. However, that would be as dizzy mentioned bringing in yet another thing.

We could also do a full constraint solve on it, but I seriously think that would be adding way more complexity then is really called for here.


@ericbmerritt @dizzyd to be clear, my preference is to get this patch merged as-is. It works for my use case, and I have a use for it (see the currently unfixable riaknostic issue above). I was mostly just asking if there was another rebar function that I should be calling to get the version instead of the one I wrote for this patch.


I'm also in favor of avoiding a full constraint solver and doing just a "minimum version" check.

@dizzyd dizzyd merged commit 08c5101 into basho:master
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jun 21, 2012
  1. @evanmcc

    Add support for minimum OTP versions.

    evanmcc authored
    Since you can't really do math with regexps and it's a pain to
    repeatedly update the config for each new version or erlang, I wanted
    to add support for minium OTP versions.  This is a fix for
This page is out of date. Refresh to see the latest.
Showing with 29 additions and 0 deletions.
  1. +29 −0 src/rebar_require_vsn.erl
29 src/rebar_require_vsn.erl
@@ -67,4 +67,33 @@ check_versions(Config) ->
nomatch ->
?ABORT("OTP release ~s does not match required regex ~s\n",
[erlang:system_info(otp_release), OtpRegex])
+ end,
+ case rebar_config:get(Config, require_min_otp_vsn, undefined) of
+ undefined -> ?DEBUG("Min OTP version unconfigured~n", []);
+ MinOtpVsn ->
+ {MinMaj, MinMin} = version_tuple(MinOtpVsn, "configured"),
+ {OtpMaj, OtpMin} = version_tuple(erlang:system_info(otp_release),
+ "OTP Release"),
+ case {OtpMaj, OtpMin} >= {MinMaj, MinMin} of
+ true ->
+ ?DEBUG("~s satisfies the requirement for vsn ~s~n",
+ [erlang:system_info(otp_release),
+ MinOtpVsn]);
+ false ->
+ ?ABORT("OTP release ~s or later is required, you have: ~s~n",
+ [MinOtpVsn,
+ erlang:system_info(otp_release)])
+ end
+ end.
+version_tuple(OtpRelease, Type) ->
+ case re:run(OtpRelease, "R(\\d+)B?-?(\\d+)?", [{capture, all, list}]) of
+ {match, [_Full, Maj, Min]} ->
+ {list_to_integer(Maj), list_to_integer(Min)};
+ {match, [_Full, Maj]} ->
+ {list_to_integer(Maj), 0};
+ nomatch ->
+ ?ABORT("Cannot parse ~s version string: ~s~n",
+ [Type, OtpRelease])
Something went wrong with that request. Please try again.