Selecting a release for a new project

[9a3eedi]

We're looking into starting a new project with cFS. We would like to start from a released version and stick to it as we develop our code. However, it's not really clear which release we should target. The README and Github says that Aquila is the latest release, but this is from 2020, and there have been many "pre-releases" since then. Notably we noticed that the latest git version contains a lot of improvements in general when compared to Aquila, and ideally we would like to use those improvements.

A small question, what does "rc" actually mean? I thought it meant "release candidate", i.e. not an actual release, but close to one. But is that the intention, or is this more of an actual release that can be used for new project?

So would it be a good idea to stick to Aquila, or perhaps use one of the pre-releases?

[skliper]

Release candidates (rc) are checkpoints where the development team has completed everything up to the submittal to software release processing folks for approval as an official release. Occasionally there's a week or to of finalizing artifacts and getting them all loaded after an rc is created, but it's usually fairly quick.

Note not every rc gets submitted to software release folks, but it's a version that has all the artifacts/processes/testing applied such that it could. Historically software release processing has taken up to 18 months, and could be up to 2 years from what I'm told, which is why we separate the two activities if projects do want to use the rc. It's a project choice if this software release processing (basically paperwork and "official release" designation) is value added.

I typically just use the latest RC (and occasionally advance if I need a bug fix or change that got merged).

[9a3eedi]

I see, so one can treat these release candidates as "official unofficial releases".

So if I understand correctly, release candidates within the same development cycle do not contain breaking changes, while different development cycles may contain breaking changes. For example, if we started with Draco rc1, then it would not break anything if we decided to upgrade to Draco rc2-rc4, but things may break if we decide to upgrade to Equuleus-rc1. Is this correct?

[skliper]

RC's and dev cycles are more for coordinating across open source components and project needs for a checkpoint, version numbers are for impact.

In theory "breaking" changes are indicated by major version number updates (6.9.1 to 7.0.0), and there's a best-effort attempt to keep changes within a major version number backwards compatible. Note sometimes changes sneak in where using open source cFS components across minor versions or rc's does break (using Draco-rc1 osal with Draco-rc4 cfe might not actually work), but the impacts to external apps should be at most minimal. Occasionally custom config a project may be using can break if they do something unanticipated or uncovered by open source CI, but again best effort is made to keep things backwards compatible until there's a major version number update.

[9a3eedi]

Understood, thank you for the clarification.