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 <mike.hol...@linaro.org> 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 <ola.liljed...@linaro.org> 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 <taras.kondrat...@linaro.org>
>> 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 <taras.kondrat...@linaro.org>
>>> Signed-off-by: Taras Kondratiuk <ta...@ti.com>
>>> ---
>>> 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
>>> lng-odp@lists.linaro.org
>>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>>
>>
>>
>> _______________________________________________
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>
>
> --
> *Mike Holmes*
> Linaro Technical Manager / Lead
> LNG - ODP
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
