Skip to content

SDK Versioning

Overview

OpenJAUS SDK releases are versioned as a bundle package using the year of the release and a release number. Release numbers start at 0 and are incremented for each release within the given year.

Examples:

  • 2021.0 -- the first release in 2021
  • 2023.0 -- the first release in 2023
  • 2023.1 -- the second release in 2023

Individual library packages within an SDK bundle (see Overview) are versioned using Semantic Versioning v2.0.0.

Compatibility between SDK releases is not guaranteed and should be evaluated based on the versions of the individual packages within the SDK bundle package.

What happens if I upgrade?

Assuming:

  • You are using SDK YYYY.0, which consists of:
    • org.openjaus.cpp v1.0.0
    • org.openjaus.core-v1.1.cpp v1.0.0
    • org.openjaus.mobility-v1.0.cpp v1.0.0
  • We release SDK YYYY.1. What happens if you upgrade to this version?

Possibility 1: Full Compatibility

If SDK YYYY.1 contains:

  • org.openjaus.cpp v1.0.1
  • org.openjaus.core-v1.1.cpp v1.1.0
  • org.openjaus.mobility-v1.0.cpp v1.0.0

Then SDK YYYY.1 is fully backwards compatible with SDK YYYY.0 and is a drop in replacement. There should be no changes required to your final application.

Upgrading to SDK YYYY.1 will:

  • Fix a bug in the base libraries.
  • Give you access to some new capability in the core v1.1 service set.
  • Have no impact on code that depends on the mobility v1.0 service set.

Possibility 2: Partial Compatibility

If SDK YYYY.1 contains:

  • org.openjaus.cpp v1.0.1
  • org.openjaus.core-v1.1.cpp v1.1.0
  • org.openjaus.mobility-v1.0.cpp v2.0.0

Then SDK YYYY.1 is partially backwards compatible with SDK YYYY.0. If you use any of the services in the mobility v1.0 service set, then upgrading may cause your final application to not compile, or change its behavior. However, if you don't use any services in the mobility v1.0 service set, your final application will not be impacted. You will need to review the associated CHANGELOG.md file to understand the potential impacts on your application.

Upgrading to SDK YYYY.1 will:

  • Fix a bug in the base libraries.
  • Give you access to some new capability in the core v1.1 service set.
  • Potentially break code that depends on the mobility v1.0 service set.

Possibility 3: Potentially Incompatible

If SDK YYYY.1 contains:

  • org.openjaus.cpp v2.0.0
  • org.openjaus.core-v1.1.cpp v2.0.0
  • org.openjaus.mobility-v1.0.cpp v2.0.0

Then SDK YYYY.1 is potentially incompatible with SDK YYYY.0 such that upgrading may cause your final application to not compile, or its behavior may change. You will need to review the associated CHANGELOG.md file to understand the potential impacts on your application.

Upgrading to SDK YYYY.1 will:

  • Potentially break code that depends on the base libraries.
  • Potentially break code that depends on the core v1.1 service set.
  • Potentially break code that depends on the mobility v1.0 service set.

Possibility 4: Backwards Compatible Service Set Version Change

If SDK YYYY.1 contains:

  • org.openjaus.cpp v1.0.1
  • org.openjaus.core-v1.1.cpp v1.1.0
  • org.openjaus.mobility-v1.1.cpp v1.0.0
    • !! The mobility service set is updated from v1.0 to v1.1

Then SDK YYYY.1 is at least partially backwards compatible with SDK YYYY.0. If you use any of the services in the mobility v1.0 service set, then upgrading may cause your final application to not compile, or change its behavior. However, if you don't use any services in the mobility v1.0 service set, your final application will not be impacted.

Info

Although all services in mobility v1.0 and mobility v1.1 are backwards compatible at the service level, the C++ code that implements the service sets may or may not be. The JSIDL service definitions could produce code that is similar or completely different, making it almost impossible to guarantee compatibility or incompatibility at the code level. Similarly, identifying the changes that occurred are very difficult such they cannot be provided in the associated CHANGELOG.md.

Upgrading to SDK YYYY.1 will:

  • Fix a bug in the base libraries.
  • Give you access to some new capability in the core v1.1 service set.
  • Potentially break code that depends on the mobility v1.0 service set.
  • Produce an application that is service-level compatible with the previous version.

Possibility 5: Incompatible Service Set Version Change

If SDK YYYY.1 contains:

  • org.openjaus.cpp v1.0.1
  • org.openjaus.core-v1.1.cpp v1.1.0
  • org.openjaus.mobility-v2.0.cpp v1.0.0
    • !! The mobility service set is updated from v1.0 to v2.0

Then SDK YYYY.1 is at least partially backwards compatible with SDK YYYY.0. If you use any of the services in the mobility v1.0 service set, then upgrading may cause your final application to not compile, or change its behavior. However, if you don't use any services in the mobility v1.0 service set, your final application will not be impacted.

Info

Although, not all services in mobility v1.0 and mobility v2.0 are backwards compatible at the service level, the C++ code that implement the service sets may or may not be. The JSIDL service definitions could produce code that is similar or completely different, making it almost impossible to guarantee compatibility or incompatibility at the code level. Similarly, identifying the changes that occurred are very difficult such they cannot be provided in the associated CHANGELOG.md.

In addition, even if the code is compatible, the behavior of the services used may have changed from v1.0 to v2.0. As such, care should be taken to review the differences between the services in mobility v1.0 and mobility v2.0 to understand the potential impacts on your application.

Upgrading to SDK YYYY.1 will:

  • Fix a bug in the base libraries.
  • Give you access to some new capability in the core v1.1 service set.
  • Potentially break code that depends on the mobility v1.0 service set.
  • Potentially produce an application that is not service-level compatible with the previous version.