Related to versioning frequency and for your thoughts and inclusion in the ARC doc with the above info
I don't think we should have weekly, monthly or other period internal releases only Public ones, instead the expectation would be like this. All patches no matter what compile for all public platforms (a driver towards public participation in line with linux, the modifier of code must address your platform as necessary) New Feature Caveats:- - new features only have to compile on all platforms, i.e it is ok to add stubs to DPDK,netmap & KS2 for a new API that is only fully implemented on linux-generic - new features have a minimal validation test at 1st patch submission so that other platforms can start working towards compliance - Obviously by every full release the validation suite is completed by all public platforms, others are free to prove compliance later on their own schedule - The validation suite is contributed to by all platform developers (private implementations as well if LNG members) before a public release ensure we do everything we can to specify how that feature should behave in the test suite. Bug Fixes to existing APIs Caveats:- - Patches must work for all public platforms, the validation tests must be run, this should be via private or possibly Maxims public staging branch. but you won't want it to get to him before it fails. CI makes these staging run set ups for your own git repo easy. On 5 September 2014 11:26, Bill Fischofer <[email protected]> wrote: > We also need to remember that pre-v1.0 we've made no guarantees of API > stability. That's one of the big milestones for ODP v1.0--that APIs have > achieved stability. As part of the v1.0 delivery, everything in the > repository should be at a v1.0 level--so there should be no need for any of > this until post-v1.0 delivery. > > Going forward, API changes need to be subject to release versioning. > Following Mike's points, anything that's not backward-compatible with v1.0 > would need to be v2.0. If we do a v1.1, etc. it would only be to add or > extend things in a compatible manner. Patches (v1.0.1, etc.) are just bug > fixes and can have no API changes. > > One of the things we'll be discussing with the LNG-SC during LCU is > expectations for support (e.g., do we need a v1.0 LTS even after v2.0 shows > up, etc.). All part of the "growing pains" of having real users for > ODP--something we certainly want. > > Bill > > > On Fri, Sep 5, 2014 at 10:06 AM, Mike Holmes <[email protected]> > wrote: > >> >> - Major version numbers change whenever there is something >> significant, a large or potentially backward-incompatible change to a >> software package. >> - Minor version numbers change when a new, minor feature is >> introduced, or when a set of smaller features is rolled out. >> - Patch numbers change when a new build of the software is released >> to customers. This is normally for small bugfixes or the like. >> >> >> >> On 5 September 2014 10:54, Ola Liljedahl <[email protected]> >> wrote: >> >>> Good idea. >>> What's the strict meaning of the a/b/c numbers? I would like to see a >>> definition on how these numbers change when you make common changes. >>> E.g. >>> add function or type >>> remove function or type >>> syntactical change (but same semantics so functionally backwards >>> compatible), maybe adding an argument or change in header files >>> semantic change (but same syntax so existing code would compile but >>> perhaps not run as expected) >>> other cases? >>> >>> -- Ola >>> >>> >>> >>> >>> On 5 September 2014 15:51, Taras Kondratiuk <[email protected] >>> > wrote: >>> >>>> API and header names will evolve and change continuously. Some changes >>>> may be not backward compatible. Application need some mechanism to >>>> support at least a few recent revisions of ODP API. Hence add a few >>>> macros to be able to compare ODP API versions. >>>> >>>> Macros can be used in a following way: >>>> >>>> #include <odp_version.h> >>>> #if ODP_VERSION_API >= ODP_VERSION(2,0,0) >>>> /* Call ODP v2.0 API */ >>>> #elif ODP_VERSION_API >= ODP_VERSION(1,0,0) >>>> /* Call ODP v1.0 API */ >>>> #else >>>> /* Call pre v1.0 API */ >>>> #endif >>>> >>>> Signed-off-by: Taras Kondratiuk <[email protected]> >>>> Signed-off-by: Taras Kondratiuk <[email protected]> >>>> --- >>>> platform/linux-generic/include/api/odp_version.h | 16 >>>> ++++++++++++++++ >>>> 1 file changed, 16 insertions(+) >>>> >>>> diff --git a/platform/linux-generic/include/api/odp_version.h >>>> b/platform/linux-generic/include/api/odp_version.h >>>> index c823e2d..97f8e26 100644 >>>> --- a/platform/linux-generic/include/api/odp_version.h >>>> +++ b/platform/linux-generic/include/api/odp_version.h >>>> @@ -44,6 +44,22 @@ extern "C" { >>>> */ >>>> #define ODP_VERSION_API_BUG 1 >>>> >>>> +/** >>>> + * Macro to merge three parts of ODP API version into one word >>>> + * >>>> + * Merge ODP version into one word: >>>> + * byte 0 - bug correction version >>>> + * byte 1 - sub version >>>> + * byte 2 - main version >>>> + */ >>>> +#define ODP_VERSION(a, b, c) (((a) << 16) + ((b) << 8) + (c)) >>>> + >>>> +/** >>>> + * Current version of ODP API in one word form >>>> + */ >>>> +#define ODP_VERSION_API ODP_VERSION((ODP_VERSION_API_MAIN), \ >>>> + (ODP_VERSION_API_SUB), \ >>>> + (ODP_VERSION_API_BUG)) >>>> >>>> /** @internal Version string expand */ >>>> #define ODP_VERSION_STR_EXPAND(x) #x >>>> -- >>>> 1.7.9.5 >>>> >>>> >>>> _______________________________________________ >>>> lng-odp mailing list >>>> [email protected] >>>> http://lists.linaro.org/mailman/listinfo/lng-odp >>>> >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> [email protected] >>> http://lists.linaro.org/mailman/listinfo/lng-odp >>> >>> >> >> >> -- >> *Mike Holmes* >> Linaro Technical Manager / Lead >> LNG - ODP >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> http://lists.linaro.org/mailman/listinfo/lng-odp >> >> > -- *Mike Holmes* Linaro Technical Manager / Lead LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
