On 3 October 2014 08:47, Savolainen, Petri (NSN - FI/Espoo) < petri.savolai...@nsn.com> wrote:
> We should release more often than once per year. A large application > cannot be ported/developed/maintained on the development branch. It’s > easier to follow multiple small steps, than e.g. port from v1.0 to v2.0 in > one big bang. > Don't disagree, as long as we do agree on what is in it > -Petri > > > > *From:* lng-odp-boun...@lists.linaro.org [mailto: > lng-odp-boun...@lists.linaro.org] *On Behalf Of *ext Bill Fischofer > *Sent:* Friday, October 03, 2014 3:24 PM > *To:* Mike Holmes > *Cc:* lng-odp > *Subject:* Re: [lng-odp] [ARCH PATCH v3] Add release management > > > > There seems to be some continuing confusion as to what constitutes an ODP > Release. To date we've had exactly two: v0.1 released December 2013, and > v0.2 released March 2014. We also stated there would be no API > compatibility claims prior to v1.0. > > > > An ODP Release is a tag on the repository that denotes a specific set of > (documented) functionality. Right now the only Releases planned by this > definition are v1.0 planned for December 2014 and v2.0 planned for December > 2015. > > > > The "live" ODP git tree is not a release and those working with the tip > have no guarantees of any API stability. All of this discussion relates to > statements we make about tagged releases, not what happens at the tip on a > day to day or month to month basis. > > > > If we choose to make a tagged release after v1.0 but before December 2015, > we'll then pick a number based on the functional delta from the v1.0 base. > If there's reason to tag a release in June 2015, for example, then we'll > call it v1.x or v2.0 based on what's in it. If we wind up calling it v2.0 > then what we tag in December 2015 will again be called either v2.x or v3.0 > based on what's in it. > > > > Does that help? > > > > Bill > > > > On Fri, Oct 3, 2014 at 6:34 AM, Mike Holmes <mike.hol...@linaro.org> > wrote: > > Taras, Petri, please propose a patch with alternate wording. > > > > If we want to put the text in the API file that is fine with me. I think > we should give it a module name though so that it becomes a highlighted > section in the doc and not buried inside that files documentation. > > > > Mike > > > > On 3 October 2014 04:39, Taras Kondratiuk <taras.kondrat...@linaro.org> > wrote: > > On 10/02/2014 11:12 PM, Mike Holmes wrote: > > > > On 2 October 2014 11:55, Taras Kondratiuk <taras.kondrat...@linaro.org > <mailto:taras.kondrat...@linaro.org>> wrote: > > On 09/29/2014 09:24 PM, Mike Holmes wrote: > > Signed-off-by: Mike Holmes <mike.hol...@linaro.org > <mailto:mike.hol...@linaro.org>> > --- > release.dox | 54 > ++++++++++++++++++++++++++++++__++++++++++++++++++++++++ > > > 1 file changed, 54 insertions(+) > create mode 100644 release.dox > > diff --git a/release.dox b/release.dox > new file mode 100644 > index 0000000..53301ac > --- /dev/null > +++ b/release.dox > @@ -0,0 +1,54 @@ > +/* Copyright (c) 2014, Linaro Limited > + * All rights reserved > + * > + * SPDX-License-Identifier: BSD-3-Clause > + */ > + > +/** > +@page release Release Management > +@tableofcontents > +@section release_numbering Numbering > + > +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. > + > +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. > +Every change in API version will require a recompilation, > relinking will not be sufficient. > + > +The ODP API major.minor version will only change at > well-defined release points. > +A release will be tagged @code ODP-<major>.<minor> @endcode and > bug fix releases on the platform will be tagged @code > ODP-<major>.<minor>.<sub> @endcode first bug fix release sub = 1. > + > +@subsection major Major > +The major digit is the ODP API generation. > +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 element to an enum that is an output from ODP > + > +@subsection minor 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 one. > +- New element to an enum that is an input to ODP > + > +@subsection sub Sub > +The sub digit is used for backward compatible changes > +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 > +- bug fixes in implementation > > > That is a version of API and should not be related to any > implementation. > > + > +*/ > > > IMO having only Major number for backward incompatible changes is not > enough. I assume each our release during the next year won't be > backward compatible, so we will bump major number too often. > > > What does too often mean ? > The Linux major number is worthless, it only changes when Linus decides > he wants a change, it means nothing. > > > Linux is not a good example because it has different release policy. > Linus doesn't set/communicate expectations on what is included in which > release. But we do by saying that v1.x is kind of evaluation-ready and > v2.x will be production-ready. > > GCC has been around since T-Rex (Cretaceous period) ate Triceratops > for breakfast and they only made it to 4.x, so far is that good or is > it bad ? > > The important thing is that you know what a change in number means not > that it is a big or little number. > > > That's an important thing why I'd like to have two numbers for backward > incompatible changes. Two number gives more granularity to describe a > 'size' of incompatibility. Let's say in one number case it is not clear > what amount of changes need to be done to migrate from version 12 to 13 > of ODP API. But in two number case I'd expect that minor version change > will need only a few percent of application code touched. While major > number change may cause a complete application redesign. > > Also I expect we will end up having LTS branches for each major release > number, because developers may not want to do significant redesign of > their application, but want to use some features added in new versions. > > > > > > -- > > *Mike Holmes* > > Linaro Sr Technical Manager > > LNG - ODP > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp > > > -- *Mike Holmes* Linaro Sr Technical Manager LNG - ODP
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
