-
Notifications
You must be signed in to change notification settings - Fork 517
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tag usage in newer rebar3 versions #2846
Comments
Hi. Is there an update on this problem? We were trying to find a solution using tags consisting of only 3 numbers but unfortunately it wont solve our problem. We need to tag hotfixes with 4 numbers or with some postfix following the third number. As mentioned above none of these two options work. Do you think its a valid problem which should be addressed or can you see any other possible solution? |
No updates. I've cut back some of my maintaining time for OSS stuff as I'm doing other things in my life (and also side projects that aren't just builds), and as such I've tackled generally blocking bugs or compatibility issues across Erlang versions, but I don't have the bandwidth to do deeper overhauls within the tooling. The apparent thing is that relx started only supporting semver somewhere in 2020 as part of its 4.0 version, which we introduced in Rebar3 3.14.0 back in August 2020. These fixes to go for semver were made as part of some refactorings to properly sort versions while trying to support systools updates that happened back then. At this point I'm not really sure what is safe or not to do, or how we could do comparison of non-semver versions with semver versions if we were to support both; the change has been there for a long enough time that undoing it is its own risk as well, so it's not a simple change for sure. |
You can put basically anything after a |
No, unfortunately using a tag like 0.1.0+build1 is not possible. Using rebar3 3.22.1 it fails with
even though the release has been generated for that tag
|
|
I've pushed a repository here, where it does not work: https://github.com/tothlac/oyhveyh/ tothlac:oyhveyh cat ~/work/upgr.sh
#!/bin/bash
set -ex
APP=$1
BASE=$2
TARGET=$3
printf "Upgrade on %s between versions %s ==> %s\n" ${APP} ${BASE} ${TARGET}
rm -rf _build
git reset --hard ${BASE}
rebar3 release
git reset --hard ${TARGET}
rebar3 release
rebar3 appup generate
rebar3 relup --relname ${APP} --relvsn ${TARGET} then I called
It works with target tag 0.1.1, but does not work with 0.1.0+build1 because I got the above mentioned problem |
Oh, is this only an issue for relups? |
You say it is "newer rebar3" tho, did using such version tags used to work? |
Sorry, why did I not reread the origin post, haha. I see it is two separate issues for using 4 digits and using The latter is possibly a systools issue since it is an issue in relups. I need to check where that error message comes from. |
Ok, it is a bug in relx_relup it appears. I don't know why |
Actually either tags containing four numbers (4.2.1.10) or three numbers + something at the end like 4.2.1+build1 would be good for us. Unfortunately 3 numbers is not enough for us, we would like to use something after the third number. I've just tried it with 4.2.1-build1, but that one also does not work, even though: tothlac:oyhveyh ls _build/default/rel/oyhveyh/releases/
0.1.0 0.1.0-build1 RELEASES start_erl.data |
I got this: tothlac:oyhveyh ../upgr.sh oyhveyh 0.1.0 0.1.0-build1
+ APP=oyhveyh
+ BASE=0.1.0
+ TARGET=0.1.0-build1
+ printf 'Upgrade on %s between versions %s ==> %s\n' oyhveyh 0.1.0 0.1.0-build1
Upgrade on oyhveyh between versions 0.1.0 ==> 0.1.0-build1
+ rm -rf _build
+ git reset --hard 0.1.0
HEAD is now at d01dff0 Add appup plugin
+ rebar3 release
===> Fetching rebar3_appup_plugin (from {git,"https://github.com/lrascao/rebar3_appup_plugin.git",
{branch,"master"}})
===> Fetching bbmustache v1.5.0
===> Fetching string_compat v0.0.1
===> Analyzing applications...
===> Compiling string_compat
===> Compiling bbmustache
===> Compiling rebar3_appup_plugin
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling oyhveyh
===> Assembling release oyhveyh-0.1.0...
===> Release successfully assembled: _build/default/rel/oyhveyh
+ git reset --hard 0.1.0-build1
HEAD is now at 87ca560 Add cowboy
+ rebar3 release
===> Verifying dependencies...
===> Fetching cowboy v2.11.0
===> Fetching cowlib v2.12.1
===> Fetching ranch v1.8.0
===> Analyzing applications...
===> Compiling cowlib
===> Compiling ranch
===> Compiling cowboy
===> Analyzing applications...
===> Compiling oyhveyh
===> Assembling release oyhveyh-0.1.0-build1...
===> Release successfully assembled: _build/default/rel/oyhveyh
+ rebar3 appup generate
===> current base dir: "/Users/tothlac/work/oyhveyh/_build/default"
===> app oyhveyh ebin dir: "/Users/tothlac/work/oyhveyh/_build/default/lib/oyhveyh/ebin"
===> Generated appup ("0.1.0" <-> "0.1.0-build1") for oyhveyh in "/Users/tothlac/work/oyhveyh/_build/default/lib/oyhveyh/ebin/oyhveyh.appup"
+ rebar3 relup --relname oyhveyh --relvsn 0.1.0-build1
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling oyhveyh
===> Assembling release oyhveyh-0.1.0-build1...
===> Release successfully assembled: _build/default/rel/oyhveyh
===> Upfrom release version (0.1.0-build1) for relup not found |
Do you have any updates on this? |
No updates at this point in time. |
We use tags like 3.13.3 for our main versions, and sometimes when there is a problem on the production server we release a hotfix. We tag it as 3.13.3.1, then 3.13.3.2, etc.
It was working in older versions of rebar3 (3.13.x), in newer versions (3.18.0) I got an error when I run
I got this:
Let's suppose I already have created 3.13.4, so I can't use that tag for the hotfix release. I've also tried to use 3.13.3-hotfix for the target, but that also fails.
What would you advice? What tag should I use for the hotfix which works in these newer rebar3 versions?
I got the error using this script:
The text was updated successfully, but these errors were encountered: