Difference between revisions of "Version Retention Policy"

From Openembedded.org
Jump to: navigation, search
 
Line 1: Line 1:
{{Outdated}}
 
 
 
== Background ==
 
== Background ==
  
 
The OpenEmbedded community has agreed and the TSC has discussed the creation of a policy for how long to retain (and when to replace and remove) old recipes and what should happen at that time, with regards to oe-core and meta-oe and associated layers.
 
The OpenEmbedded community has agreed and the TSC has discussed the creation of a policy for how long to retain (and when to replace and remove) old recipes and what should happen at that time, with regards to oe-core and meta-oe and associated layers.
  
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.
+
OE-Core aims to contain recent versions its components and those versions will get updated to newer versions as they are released. In general multiple versions would only be avaiable in OE-Core if there was some known issue with the latest version preventing an upgrade and those issues would usually be being worked on with a view to completing the version upgrade. One other exception to this rule is where recipes are being preserved for licensing reasons such as GPLv2 vs GPLv3.
 +
 
 +
The meta-oe repository is available to preserve older versions of components while they are still useful and desirable to maintain and these would be moved there based upon community demand.
  
 
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.
 
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.

Latest revision as of 10:06, 7 November 2012

[edit] Background

The OpenEmbedded community has agreed and the TSC has discussed the creation of a policy for how long to retain (and when to replace and remove) old recipes and what should happen at that time, with regards to oe-core and meta-oe and associated layers.

OE-Core aims to contain recent versions its components and those versions will get updated to newer versions as they are released. In general multiple versions would only be avaiable in OE-Core if there was some known issue with the latest version preventing an upgrade and those issues would usually be being worked on with a view to completing the version upgrade. One other exception to this rule is where recipes are being preserved for licensing reasons such as GPLv2 vs GPLv3.

The meta-oe repository is available to preserve older versions of components while they are still useful and desirable to maintain and these would be moved there based upon community demand.

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.

[edit] Policy

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. The definition of which packages are in which categories is outside of the scope of this policy.

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).
Personal tools
Namespaces

Variants
Actions
Navigation
Categories
OE services
Toolbox