Time to nail down the usage of format_version of Autoware Lanelet2 map

[soblin]

As described here, Autoware Lanelet2 extension defines "MetaInfo" tag to let the user know when new RegulatoryElement / map primitives have been introduced. There has been no release cycle for the "format_version" so far and the version has been "1" all the time, but for future changes and compatibility it's a good time to start strict versioning of format_version.

Overall we should release (or should have released) a major format_version when a new RegulatoryElement / sub-type is introduced because the lanelet2_extension package as well as the depending modules like the map_loader depend on a new primitive that's not available in the prior format. One example of this is the crosswalk lanelet and the crosswalk regulatory element. croswalk regulatory element was later introduced, so the user using old Autoware.universe will need to update their software if the map contained them. But current Autoware cannot handle format_version discrepancy because it has no information on its supporting format_version in its binary.

To provide compatibility and support information as an OSS, I am making two PRs and would like to propose release cycle.

lanelet2_extension

Our latest release of format_version is 1, and when we want to

• introduce a new RegulatoryElement, sub-types, etc. or deprecate/modify existing primitives, we'll release a major version. It will be 2 next.
• change small specs, use-cases, validation rules, we'll release a minor version.

Related functions should be placed under the namespace lanelet::module::vN where N denotes the major version.

The latest version or namespace is declared as the inline namespace vN because it provides the default API, and deprecated/old APIs are placed under namespace v(N-1) where (N-1) denotes the prior major version. In this way we can tell the developers that symbols under inline namespace v(N-1) now have moved to namespace v(N-1) and they have to change part their code if they explicitly use old APIs.

Following snippet describes the namespacing.

before release of v1

inline namespace v1{
class RE1 {}; // keep
class RE3 {}; // will be deleted in v2
}

after release of v2

namespace v1{
class RE3 {}; // deleted in v2
}

inline namespace v2{
class RE1 {}; // keep
class RE2 {}; // added in v2
}

PR: autowarefoundation/autoware_common#245

map_loader

If the binary of map_loader does not support the format_version of the provided map, it should abort. I'm adding a PR to abort map_loader in that case, unless it is explicitly defined by the parameter.

autowarefoundation/autoware.universe#7074