[libvirt] [PATCH glib] README: formally document intended platform support targets
Give users an indication of what distro platforms the project intends to be buildable on. This policy will be used to decide when it is appropriate to increase the minimum required versions of external dependancies. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- README | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 53 insertions(+), 12 deletions(-) diff --git a/README b/README index 3108e3c..3547089 100644 --- a/README +++ b/README @@ -26,18 +26,59 @@ The latest official releases can be found at: NB: at this time, libvirt-glib is *NOT* considered API/ABI stable. Future releases may still include API/ABI incompatible changes. -Dependencies -============ - -- Required: - - glib-2.0 - - gobject-2.0 - - libxml-2.0 - - libvirt - -- Optional: - - gobject-introspection - - Vala (build-time only) +Dependencies / supported platforms +================================== + +The libvirt-glib projects attempts to be moderately conservative +about updating the minimum required versions of external package +dependencies, to strike a balance between enabling use of new +features while minimizing inconvenience for downstream developers +on distro platforms with specific shipped version. + +There are commonly two classes of Linux distro - short lifetime +(Fedora, Ubuntu non-LTS, etc) and extended lifetime (RHEL, CentOS, +Debian, Ubuntu LTS). Based on this classification, the libvirt-glib +project will generally aim to ensure build support for + + - Most recent 2 releases of short lifetime distros + - Most recent major release of extended lifetime distros, + with most recent 2 minor updates + +The project will consider RHEL, Fedora, Ubuntu LTS, Ubuntu, OpenSUSE +and SUSE (SLES/SLED) distros to be a representative subset of distros +when determining min required versions of external deps, as other distros +of similar release vintage will typically have similar versions. In the +case of Debian, the project may at times choose to require use of an +update from the backports repository. + +As an example, as of July 1st 2015 this policy would imply that the +following distros are officially targetted as buildable platforms: + + - RHEL: 7.1, 7.2 + - Fedora: 21, 22 + - Ubuntu LTS: 14.04 (Trusty) + - Ubuntu: 14.10 (Utopic), 15.04 (Vivid) + - Suse: 12.0 + - OpenSUSE: 13.1, 13.2 + - Debian: 8.0 (Jessie) + +At any time, it may be possible to build on versions of distros +that are older than those implied by this policy, but the project +will not guarantee this remains the case in future releases. The +min required package versions of external dependancies may be +raised in future releases based on this distro build target policy. + +The packages required to build libvirt-glib are + + - glib-2.0 + - gobject-2.0 + - libxml-2.0 + - libvirt + +Functionality is optionally enhanced by the following packages: + + - gobject-introspection + - Vala (build-time only) Patches sumissions ================== -- 2.4.3
On Wed, Jul 22, 2015 at 2:02 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
Give users an indication of what distro platforms the project intends to be buildable on. This policy will be used to decide when it is appropriate to increase the minimum required versions of external dependancies.
While this sounds like a good idea at first, being so specific about versions makes it a very bad one IMO. i-e this list will get outdated all the time and none of us will remember to update it often enough for it to be useful. Also IMO selecting a few downstreams isn't a good idea in upstream project. We really should be distro-agnostic and libosinfo should be buildable on any GNU/Linux distro. The idea here is to convey the message "We do care a lot about individual distros" but unless this list is a long one, we are actually saying "We only care of these distros". As I said before, I think we only need to define a time frame in upstream (i-e we guarantee we won't bump any dep to anything newer than X amount of time) and be done with it. No need to focus on any particular distros, just provide enough time for distros. In worse case, they'd have to cherry-pick fixes from newer version of software, which is what long-term support downstream typically imply anyway.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- README | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 53 insertions(+), 12 deletions(-)
diff --git a/README b/README index 3108e3c..3547089 100644 --- a/README +++ b/README @@ -26,18 +26,59 @@ The latest official releases can be found at: NB: at this time, libvirt-glib is *NOT* considered API/ABI stable. Future releases may still include API/ABI incompatible changes.
-Dependencies -============ - -- Required: - - glib-2.0 - - gobject-2.0 - - libxml-2.0 - - libvirt - -- Optional: - - gobject-introspection - - Vala (build-time only) +Dependencies / supported platforms +================================== + +The libvirt-glib projects attempts to be moderately conservative +about updating the minimum required versions of external package +dependencies, to strike a balance between enabling use of new +features while minimizing inconvenience for downstream developers +on distro platforms with specific shipped version. + +There are commonly two classes of Linux distro - short lifetime +(Fedora, Ubuntu non-LTS, etc) and extended lifetime (RHEL, CentOS, +Debian, Ubuntu LTS). Based on this classification, the libvirt-glib +project will generally aim to ensure build support for + + - Most recent 2 releases of short lifetime distros + - Most recent major release of extended lifetime distros, + with most recent 2 minor updates + +The project will consider RHEL, Fedora, Ubuntu LTS, Ubuntu, OpenSUSE +and SUSE (SLES/SLED) distros to be a representative subset of distros +when determining min required versions of external deps, as other distros +of similar release vintage will typically have similar versions. In the +case of Debian, the project may at times choose to require use of an +update from the backports repository. + +As an example, as of July 1st 2015 this policy would imply that the +following distros are officially targetted as buildable platforms: + + - RHEL: 7.1, 7.2 + - Fedora: 21, 22 + - Ubuntu LTS: 14.04 (Trusty) + - Ubuntu: 14.10 (Utopic), 15.04 (Vivid) + - Suse: 12.0 + - OpenSUSE: 13.1, 13.2 + - Debian: 8.0 (Jessie) + +At any time, it may be possible to build on versions of distros +that are older than those implied by this policy, but the project +will not guarantee this remains the case in future releases. The +min required package versions of external dependancies may be +raised in future releases based on this distro build target policy. + +The packages required to build libvirt-glib are + + - glib-2.0 + - gobject-2.0 + - libxml-2.0 + - libvirt + +Functionality is optionally enhanced by the following packages: + + - gobject-introspection + - Vala (build-time only)
Patches sumissions ================== -- 2.4.3
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Regards, Zeeshan Ali (Khattak) ________________________________________ Befriend GNOME: http://www.gnome.org/friends/
On Wed, Jul 22, 2015 at 02:54:17PM +0100, Zeeshan Ali (Khattak) wrote:
On Wed, Jul 22, 2015 at 2:02 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
Give users an indication of what distro platforms the project intends to be buildable on. This policy will be used to decide when it is appropriate to increase the minimum required versions of external dependancies.
While this sounds like a good idea at first, being so specific about versions makes it a very bad one IMO. i-e this list will get outdated all the time and none of us will remember to update it often enough for it to be useful.
The intention isn't actually to updated the README with new releases, rather just give this as an illustrative example, to explain how the policy works. ie accepts RHEL-7, but discounts RHEL-6.
Also IMO selecting a few downstreams isn't a good idea in upstream project. We really should be distro-agnostic and libosinfo should be buildable on any GNU/Linux distro. The idea here is to convey the message "We do care a lot about individual distros" but unless this list is a long one, we are actually saying "We only care of these distros".
It isn't about favouring specific distros, it is about selecting a handful of distros to use as representative samples. Distros released at a similar time tend to have similar package versions, so we're using this set of distros as a way to guage the typically available set of min versions across the bigger pool.
As I said before, I think we only need to define a time frame in upstream (i-e we guarantee we won't bump any dep to anything newer than X amount of time) and be done with it. No need to focus on any particular distros, just provide enough time for distros. In worse case, they'd have to cherry-pick fixes from newer version of software, which is what long-term support downstream typically imply anyway.
Giving time based rules really doesn't work with enterprise distros as they (quite reasonably) stick with older versions and shouldn't be expected to rebase, and I want developers working on such distros to be able to consume newer libvirt-glib if they desire, and likewise I want such users to be able to contribute to the development of the library. Many corporate developers don't have the luxury of using distros like Fedora as their dev platform, so if we don't ensure we remain easily buildable on reasonably current enterprise platforms, we are making life hard for those developers to contribute to the project. This isn't a theoretical problem - it has come up time & again with libvirt that users can only use RHEL as their build platform and not Fefora. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (2)
-
Daniel P. Berrange -
Zeeshan Ali (Khattak)