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 <lruzi...@redhat.com> 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 <ju...@zokormazo.info> > 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@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Lukas Ruzicka <lruzi...@redhat.com> 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 <ju...@zokormazo.info> > 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@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org >
_______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
