Discussion: Version retention policy in oe-core

[Tom Rini]

All,

As has been discussed in a few places, there needs to be a policy that 
is followed about how long to retain old recipes within the oe-core 
repository as well as what to do with older versions of things.  There 
is a related question here of when to use DEFAULT_PREFERENCE = "-1".

We also have use cases such as:
- Public distribution X uses version A (pins)
- Private distribution X uses version A
- 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.

After thinking about the brief discussion we had during todays TSC 
meeting, I would like to propose the following:

The goal of oe-core is to keep the latest stable version.  Exceptions 
will been needed for the toolchain components where architecture 
requirements or upstream problems may dictate that we need multiple 
versions (but versions for versions sake is not required, we are working 
within an SCM and retrieval of older ".z" type releases is easy).  With 
a release framework of X.Y.Z, going from X.Y.Z to X.Y.$((Z + 1)) should 
be a simple git mv.  When a new stable release happens (using the above 
example where 3.8 and 4.0 are both stable), 4.0 should be introduced 
with a DEFAULT_PREFERENCE of -1 and not moved to be the default until 
validation is complete for both oe-core and meta-oe using this version 
and the defined (separate item...) validation targets.  Once a new 
stable version is ready, it is up to meta-oe to decide if it's 
worthwhile to hold on to for now (and possibly delete even older 
versions, in this example 3.6.x).  If meta-oe passes for any reason, it 
would be up to interested layer maintainer(s) to pick it up.  In this 
case if a number of layers decide they really need it, they would be 
encouraged to volunteer to maintain it in meta-oe (as meta-oe should aim 
to support recipes that people are willing to support as needed).

When there is no clear policy from upstream we simply have to apply best 
judgement.

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).

-- 
Tom Rini
Mentor Graphics Corporation