diff --git a/README.md b/README.md index eed36eed4..fe3b0c56d 100644 --- a/README.md +++ b/README.md @@ -15,9 +15,11 @@ This distribution contains: 2. Tests and example applications 3. A directory structure and makefiles to manage it all. -Release Notes: +Version Notes: ============== +- 5.0.1: + - Minor updates (see https://github.com/nasa/osal/pull/264) - 5.0.0: RELEASE CANDIDATE - In build verification testing to be considered for official release - Release documentation in work diff --git a/src/os/inc/osapi-version.h b/src/os/inc/osapi-version.h index 06e361120..b875151d5 100644 --- a/src/os/inc/osapi-version.h +++ b/src/os/inc/osapi-version.h @@ -18,27 +18,9 @@ #ifndef _osapi_version_h_ #define _osapi_version_h_ -/* - * Note about the OS_REVISION value: - * During development of the "next" version of OSAL (whatever number it might be), the - * OS_REVISION value should be something high (>90) to indicate the fact that this is a development - * version and not an official release version. For instance, at the time of this writing - * the official version is 4.1.1 and the next version would likely be 4.2.0. So anyone - * who uses the "bleeding edge" development branch before 4.2.0 is officially released will - * get a version that reads e.g. "4.1.91" to show that this is a pre-4.2 build. - * - * This still leaves room for patches to be applied to 4.1.1 to produce 4.1.2 if needed. - * - * During development, if an API-affecting change is introduced then the OS_REVISION value should - * be incremented with it to indicate this. Client code that depends on the new API can do a "#if" - * against the development version number e.g. "#if OSAL_API_VERSION >= 40191" and this check - * will still be valid after the version becomes 40200 (although at some point it can be cleaned - * up to reflect the official version number, it is not going to break the build in the meantime). - */ - #define OS_MAJOR_VERSION 5 #define OS_MINOR_VERSION 0 -#define OS_REVISION 0 +#define OS_REVISION 1 #define OS_MISSION_REV 0 /**