ping On 17 October 2014 11:01, Bill Fischofer <[email protected]> wrote:
> > > On Fri, Oct 17, 2014 at 9:54 AM, Mike Holmes <[email protected]> > wrote: > >> Add text defining the release procedure and release numbering. >> >> Signed-off-by: Mike Holmes <[email protected]> >> > Reviewed-by: Bill Fischofer <[email protected]> > >> --- >> release.dox | 70 >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 70 insertions(+) >> create mode 100644 release.dox >> >> diff --git a/release.dox b/release.dox >> new file mode 100644 >> index 0000000..7cde777 >> --- /dev/null >> +++ b/release.dox >> @@ -0,0 +1,70 @@ >> +/* Copyright (c) 2014, Linaro Limited >> + * All rights reserved >> + * >> + * SPDX-License-Identifier: BSD-3-Clause >> + */ >> + >> +/** >> +@page release Release Management >> +The odp.git repo contains the API which is of primary concern when >> addressing the release numbering, the linux-generic implementation is not >> the focus of the release. >> + >> +@section release_numbering Release Numbering >> (ODP-<generation>.<major>.<minor>) >> + >> +The API uses a three digit release number, for ODP this number refers to >> +- The API header definitions >> +- The reference implementation (linux-generic) >> +- The documentation >> +- The API test & validation suite that certifies each of the above. >> + >> +@image html ODP_versioning.png "Version history diagram" >> width=\textwidth >> +@image latex ODP_versioning.eps "Version histroy diagram" >> width=\textwidth >> + >> + >> +The ODP API generation.major version will only change at well-defined >> release points. >> +An API release will be tagged @code ODP-<generation>.<major>.<minor> >> @endcode and bug fix releases on the platform will be tagged @code >> ODP-<generation>.<major>.<minor>-<sub> @endcode >> +No release will ever be made without incrementing the release number, >> the change will be according to the following guidelines. >> +Every change in API version will require a recompilation, relinking will >> not be sufficient. >> +The header file odp_version.h contains helper macros for dealing with >> ODP versions in application code. >> +@note The version refers to API source compatibility and not binary >> compatibility. >> + >> +@subsection generation (ODP-<generation>) >> +The ODP generation is intended to be a very slow moving digit that will >> only increment on very significant changes the ODP API is structured. >> +A change to this digit indicates a break in backwards compatibility. >> + >> +@subsection major (ODP-<generation>.<major>) >> +A change to this digit indicates a break in backwards compatibility. >> +@note The incompatibility covers the whole ODP API, however the change >> may be a tiny change to an esoteric function that is not used by a given >> application. >> + >> +- Altering API signature >> +- Altering a structure other than adding optional items at the end. >> +- Changing the required calling sequence for APIs >> +- Changes to the installed structure i.e. the output from "make install" >> moves a file in a way that breaks compilation. >> +- New elements added to an enum that is an output from ODP. >> + >> +@subsection minor (ODP-<generation>.<major>.<minor>) >> +The minor digit is for changes that are backwards compatible. >> +For example changes such as the addition of a new API. >> +Existing application code shall not have to change if the new API is not >> used. >> +- Adding a new struct >> +- Adding a new function >> +- Adding an additional alternate API to an existing on such that the old >> API remains. >> +- New element to an enum that is an input to ODP >> + >> +@subsection sub (ODP-<generation>.<major>.<minor>-<sub>) >> +The sub digit is used for backward compatible changes >> +The sub number is implementation driven. >> +Any existing app should work as before with the caveat that a bug fix >> may change the executable behavior (hopefully improve it) >> +- Optimize the implementation >> +- Documentation updates that do not affect the API >> +- bug fixes in implementation >> + >> +@section point_release Point Release Schedule >> +Point releases will be made throughout the year, a lose target is once >> per quarter depending on the feature load. >> +For example a release 1.1.0 that is made will regularly have support >> until the next point release is made at which time support for 1.1.0 would >> be dropped. >> + >> +@section lts Long Term Stable (LTS) >> +Long term stable release will be retroactively be selected from the >> point releases already made. >> +The determination will be made by the ODP steering committee (SC). >> +The duration of support will be decided by the SC. >> + >> +*/ >> -- >> 1.9.1 >> >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> http://lists.linaro.org/mailman/listinfo/lng-odp >> > > -- *Mike Holmes* Linaro Sr Technical Manager LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
