Yeah, I don't think that nobody would test old ones, the concern about versioning is more theorical than practical.
But you talk about clean f30 installation tol and the upgraded systems are out of scope while support the upgrades from 28 and 29.
Lukas Ruzicka <lruzicka@xxxxxxxxxx> igorleak hau idatzi zuen (2019 mar. 9, lr. 04:27):
_______________________________________________I put there those numbers, because I was not expecting that somebody would want to test old releases. We are about to start validation testing for F30 and this is where I aim with these test cases and of course any later releases onwards.Modularity was semi-available in F28, it was supported in F29, but there were changes made and now it should behave slightly differently than in F29 and 28. For example, in F29 it was possible to switch a module directly using the installation command for a new stream, but this is not possible in F30. My intent was to test modularity as it is available now, in upcoming F30. I think that nobody would test for old releases, but I might be wrong.On Fri, Mar 8, 2019 at 7:04 PM Julen Landa Alustiza <julen@xxxxxxxxxxxxxx> wrote:My concern is around the minimum version constraints. >= 29 or clean >= 30, while we support and block from 28 till 29 and we're testing 30 and an upgraded box should work like a clean one for blocking purposes. What happens with the versions that are supported but out of scope of these testcases? Current modularity tests does not have any versioning constraint so we're going backward :S
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
Lukas Ruzicka <lruzicka@xxxxxxxxxx> igorleak hau idatzi zuen (2019 mar. 9, lr. 04:27):
_______________________________________________I put there those numbers, because I was not expecting that somebody would want to test old releases. We are about to start validation testing for F30 and this is where I aim with these test cases and of course any later releases onwards.Modularity was semi-available in F28, it was supported in F29, but there were changes made and now it should behave slightly differently than in F29 and 28. For example, in F29 it was possible to switch a module directly using the installation command for a new stream, but this is not possible in F30. My intent was to test modularity as it is available now, in upcoming F30. I think that nobody would test for old releases, but I might be wrong.On Fri, Mar 8, 2019 at 7:04 PM Julen Landa Alustiza <julen@xxxxxxxxxxxxxx> wrote:My concern is around the minimum version constraints. >= 29 or clean >= 30, while we support and block from 28 till 29 and we're testing 30 and an upgraded box should work like a clean one for blocking purposes. What happens with the versions that are supported but out of scope of these testcases? Current modularity tests does not have any versioning constraint so we're going backward :S
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
