Right now, when performing a relup using relx generate scripts, you need to take the tarball containing the relup of the next version and rename it to a specific filename (<relname>.tar.gz) which must be located in a specific location (releases/<version>), when you generate a tarball the filename contains the version number so this renaming is inconvenient, this PR allows for a more flexible way:
When running the unpack/install the upgrade install will search a set of locations and look for a tarball which meets the necessary criteria, it either contains the version number we're looking for or it conforms to the previous naming scheme for retro-compatibility, it then symlinks this tarball to one the release_handler is expecting (ie. releases/<version>/<relname>.tar.gz). The set of locations used to look for the user's tarball are (in order):
releases/<relname>-<version>.tar.gzreleases/<version>/<relname>-<version>.tar.gzreleases/<version>/<relname>.tar.gz
Right now, when performing a relup using relx generate scripts, you need to take the tarball containing the relup of the next version and rename it to a specific filename (
<relname>.tar.gz) which must be located in a specific location (releases/<version>), when you generate a tarball the filename contains the version number so this renaming is inconvenient, this PR allows for a more flexible way: When running the unpack/install the upgrade install will search a set of locations and look for a tarball which meets the necessary criteria, it either contains the version number we're looking for or it conforms to the previous naming scheme for retro-compatibility, it then symlinks this tarball to one the release_handler is expecting (ie.releases/<version>/<relname>.tar.gz). The set of locations used to look for the user's tarball are (in order):releases/<relname>-<version>.tar.gzreleases/<version>/<relname>-<version>.tar.gzreleases/<version>/<relname>.tar.gz