Discussion: Version retention policy in oe-core

[Mark Hatle]

This is a follow on to Tom's original post.  The attempt is to merge his
original thoughts with my own.

---

As has been discussed in a few places, there needs to be a policy that
is followed about how long to retain (or when to replace) old recipes within the
oe-core repository as well as what to do with older versions of things.

It is expected that OE will have a related meta-oe or similar layers which older
components can be moved into while they are still useful and desirable to
maintain.  However, these will be alternative versions and not the "core"
version any longer.

Within the oe-core we can divide the components into two classes.  Critical
infrastructure components and standard components.  The critical components
include the toolchain, autotools, and key libraries.  Virtually everything else
fits into the standard components bucket.

We also have use cases such as:
- Upstream provides provides support (new releases) and clear guidelines
on upgrading for version 4.0 (current), version 3.8 (previous and
stable) and version 3.6 (further previous, stable).  Upstream is also
working on version 4.1.x (unstable, active development).
- Upstream provides no clear policy about what's supported other than
current.
- Community standards indicate a specific version should be used rather then the
latest for some reason
- An architecture requires specific versions.

We would like to propose the following:

The goal of oe-core is to remain a stable, yet up-to-date set of software that
forms the foundation of the Open Embedded world.  While not everyone will be
able to agree on a broad definition of "stable, yet up-to-date" the following
guidelines will help define the rules for the inclusion and/or replacement of
different versions into the oe-core.

First, each of the packages need to be divided into two categories: Critical
Infrastructure and Core components.  If an item is neither of these, then the
oe-core is likely the wrong place for the component.

By default we want to use the latest stable version of each component.  The
latest stable version of each component is defined by the component's upstream.
 When there is no clear policy from upstream we simply have to apply best judgment.

There of course will be exceptions to the default policy.  However, when an
exception occurs it must be clearly stated and documented when and why we did
not use the latest stable version -- or why we may have multiple versions
available of a given component.  This will allow us to reevaluate the exceptions
on a timely basis and decide the exception is no longer reasonable.

Most of these exceptions will be located in the critical infrastructure
components, specifically the toolchains.  In many cases we will need to support
variants of these components either for stability or architectural reasons.

Another common exception is to meet specific policy or compatibility objectives
within the system, such as the need to support both GPLv2 and GPLv3 versions of
selected components.

If multiple versions are provided, usually the latest stable version will be
preferred, however best judgment will be used to determine the preferred version.

As existing versions of removed, if they are still desirable, they should be
moved into meta-oe or a suitable layer.

We also have the issue of upcoming development versions it is suggested that
upcoming development versions of software be worked on in specific development
layers until they have reach sufficient maturity to be considered stable and
ready for inclusion in oe-core.

Related to this are:
- We want to encourage distributions that are tracking the latest to try
and stay with the latest.
- We want to encourage recipes which people are interested in to be
maintained long term to be maintained, long term, in meta-oe.
- We want to encourage distributions to work with and add to / maintain
the core rather than deciding we have too frequent of an unhelpful churn
(which is to say 4.0.1 -> 4.0.2 of $whatever is good, 4.0.1 -> 4.4.3 of
$whatever is not).