[libvirt] [PATCH] Revert "spec: Bump minimum supported Fedora version to 29"
This reverts commit 8a1179831b5edc0a3590489eda693914fc0ff94f. It bumped the version prematurely, before the EOL of Fedora 28. Morover, this arbitrary bump did not let us perform any cleanups in the specfile. Signed-off-by: Ján Tomko <jtomko@redhat.com> --- libvirt.spec.in | 2 +- mingw-libvirt.spec.in | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 78b7f43934..5c0b4a7605 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -4,7 +4,7 @@ # that's still supported by the vendor. It may work on other distros # or versions, but no effort will be made to ensure that going forward. %define min_rhel 7 -%define min_fedora 29 +%define min_fedora 28 %if (0%{?fedora} && 0%{?fedora} >= %{min_fedora}) || (0%{?rhel} && 0%{?rhel} >= %{min_rhel}) %define supported_platform 1 diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in index 9add033669..8a96ea914c 100644 --- a/mingw-libvirt.spec.in +++ b/mingw-libvirt.spec.in @@ -3,7 +3,7 @@ # This spec file assumes you are building on a Fedora version # that's still supported by the vendor. It may work on other distros # or versions, but no effort will be made to ensure that going forward. -%define min_fedora 29 +%define min_fedora 28 %if 0%{?fedora} && 0%{?fedora} >= %{min_fedora} %define supported_platform 1 -- 2.20.1
On Tue, May 28, 2019 at 01:14:19PM +0200, Ján Tomko wrote:
This reverts commit 8a1179831b5edc0a3590489eda693914fc0ff94f.
It bumped the version prematurely, before the EOL of Fedora 28. Morover, this arbitrary bump did not let us perform any cleanups in the specfile.
Right, that said I just tagged before this commit can be in. I just won't make the binary rpms, after some discussion that's probably not useful in general. I would ACK but F28 will be dropped from support end of the week, so maybe we don't want to flip/flop that at this point, thanks, Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On Tue, 2019-05-28 at 13:34 +0200, Daniel Veillard wrote:
On Tue, May 28, 2019 at 01:14:19PM +0200, Ján Tomko wrote:
This reverts commit 8a1179831b5edc0a3590489eda693914fc0ff94f.
It bumped the version prematurely, before the EOL of Fedora 28.
Yeah, that was my bad :( I'll be more careful about releases having actually hit EOL before dropping support for them in the future.
Morover, this arbitrary bump did not let us perform any cleanups in the specfile.
Right, that said I just tagged before this commit can be in. I just won't make the binary rpms, after some discussion that's probably not useful in general.
I agree we have no use for binary RPMs, especially when things like https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/virt-preview/ exist.
I would ACK but F28 will be dropped from support end of the week, so maybe we don't want to flip/flop that at this point,
Let's just leave it as is, and just make sure we don't repeat the same mistake in the future. -- Andrea Bolognani / Red Hat / Virtualization
On Tue, May 28, 2019 at 01:51:06PM +0200, Andrea Bolognani wrote:
On Tue, 2019-05-28 at 13:34 +0200, Daniel Veillard wrote:
On Tue, May 28, 2019 at 01:14:19PM +0200, Ján Tomko wrote:
This reverts commit 8a1179831b5edc0a3590489eda693914fc0ff94f.
It bumped the version prematurely, before the EOL of Fedora 28.
Yeah, that was my bad :( I'll be more careful about releases having actually hit EOL before dropping support for them in the future.
I'd say for Fedora's case, we could happily wait even for half a year more or so - by dropping it here we did not really gain anything - all the libraries needed for libvirt to work on F28 are still way newer than stuff from the long-term supported distros. Jano
Morover, this arbitrary bump did not let us perform any cleanups in the specfile.
Right, that said I just tagged before this commit can be in. I just won't make the binary rpms, after some discussion that's probably not useful in general.
I agree we have no use for binary RPMs, especially when things like
https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/virt-preview/
exist.
I would ACK but F28 will be dropped from support end of the week, so maybe we don't want to flip/flop that at this point,
Let's just leave it as is, and just make sure we don't repeat the same mistake in the future.
On Wed, 2019-06-19 at 19:21 +0200, Ján Tomko wrote:
On Tue, May 28, 2019 at 01:51:06PM +0200, Andrea Bolognani wrote:
On Tue, 2019-05-28 at 13:34 +0200, Daniel Veillard wrote:
On Tue, May 28, 2019 at 01:14:19PM +0200, Ján Tomko wrote:
This reverts commit 8a1179831b5edc0a3590489eda693914fc0ff94f.
It bumped the version prematurely, before the EOL of Fedora 28.
Yeah, that was my bad :( I'll be more careful about releases having actually hit EOL before dropping support for them in the future.
I'd say for Fedora's case, we could happily wait even for half a year more or so - by dropping it here we did not really gain anything - all the libraries needed for libvirt to work on F28 are still way newer than stuff from the long-term supported distros.
I see where you're coming from, but at the same time we don't have the hardware capacity to keep more than two (three, if you count Rawhide) versions of Fedora at the same time on ci.centos.org, so it would be a bit disingenuous to keep allowing RPM builds to succeed months after we've considered the target out of support based on our target platform policy and even stopped running builds on it... I think a reasonable compromise would be to remove support in the release *after* the one during whose development cycle the Fedora project itself has dropped support for the OS. -- Andrea Bolognani / Red Hat / Virtualization
participants (3)
-
Andrea Bolognani -
Daniel Veillard -
Ján Tomko