8:02 a.m.
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(a)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
8:54 a.m.
On Wed, Jul 22, 2015 at 2:02 PM, Daniel P. Berrange <berrange(a)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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
Regards,
Zeeshan Ali (Khattak)
________________________________________
Befriend GNOME: http://www.gnome.org/friends/
9:04 a.m.
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(a)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 :|
3413
days inactive
3413
days old
2 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Zeeshan Ali (Khattak)