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
