| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Include the ability to open a SASL error log file in append mode
at startup vs currently implemented "rewrite-always" mode.
|
|
The appup tests for kernel, stdlib and sasl tests that the appup file
allows upgrade from the previous and current major release to the
current release. If, in the current release, the application version
was not changed compared to the previous release, then we would still
test that the appup supported the upgrade (i.e. from current release
to current release). This is now changed, in order to avoid test
failures on patch releases where kernel, stdlib and sasl are not
changed.
|
|
Add test of update instructions from current major to current
minor. Earlier only previous major to current was tested.
|
|
These tests start new nodes, and they frequently timed out on some
slow test hosts.
|
|
Appups now only support one major release back, and the tests are
updated accordingly.
Support is also added in tests for giving previous releases in a ct
config file, e.g.
{otp_releases,[{r15,"/path/to/r15/bin/erl"},
{r16,"/path/to/r16/bin/erl"},
{'17',"/path/to/17/bin/erl"}]}.
|
|
|
|
Also clean up appup_test in sasl_SUITE by removing old versions that
are no longer used.
|
|
|
|
The appup files for kernel, stdlib and sasl did not contain any
UpFromVsn and DownToVsn. This means that it was not possible to create
a relup file with systool:make_relup if any of these applications had
changed.
This commit adds entries in the appup files for a maximum of two major
releases back - all with only one upgrade instruction:
restart_new_emulator. The point is to allow relups to be generated,
but ensure that no soft upgrade is done for these three applications -
i.e. they will always cause a restart of the emulator prior to all
other upgrade instructions from other applications.
Test cases (appup_test) are added to kernel_SUITE, stdlib_SUITE and
sasl_SUITE. These all check that expected versions are matched in the
appups, and illegal versions (older than two major releases, or in any
other way illegal) do not match. The test is written in a general way
where it is assumed that the version of these applications are stepped
according the the rule that major releases step the second number,
maintenance releases step the third number and patches step the fourth
number.
|
|
|
