Release Planning 2025

[erikbosch]

• Shall we release 5.1 or 6.0
• At next AMM (May?)
• VSS-tools can be released separately
• What is NOT backward compatible (if any)

[paulboyes]

I think we should consider a spring/summer release.

[erikbosch]

Potential backward-incompatible changes (if so not to include in 5.1), to be discussed

• Pr780 #793 (based on ObstacleDetection instances, attributes and Adaptive CruiseControl #780)
  • Adding instances to ObstacleDetection branch
• GraphQL generator refactored
• Pattern keyword (used by VIN signal)

[erikbosch]

Planned content if to be created today (for VSS)

What's Changed

• Prepare for next major release by @erikbosch in Prepare for next major release #783
• Separate doc-gen from general build by @erikbosch in Separate doc-gen from general build #784
• Add Media.Played.Genre by @cws55 in Add Media.Played.Genre #781
• Add RegExp pattern for VehicleIdentification.VIN property. by @Kostadin-Ivanov in Add RegExp pattern for VehicleIdentification.VIN property. #786
• Doc Update by @erikbosch in Doc Update #788
• Add ConsumptionSinceLastRefuel by @CoffeeMoneyMakers in Add ConsumptionSinceLastRefuel #787
• Add signals for Motion Management by @erikbosch in Add signals for Motion Management #785
• Doc Update by @erikbosch in Doc Update #792
• Pr780 by @erikbosch in Pr780 #793
• Fix 24.04 build by pinning Python version by @erikbosch in Fix 24.04 build by pinning Python version #794
• D3 now bypasses Observable Notebook framework by @Giaccomole in D3 now bypasses Observable Notebook framework #801
• Clarify VSS expectations on read/write by @erikbosch in Clarify VSS expectations on read/write #796
• refactor: Unique names for the pattern {parent_banch_name}.{branch_name} by @jdacoello in refactor: Unique names for the pattern {parent_banch_name}.{branch_name} #799
• Update pre-commit version by @erikbosch in Update pre-commit version #803
• Correction of typo in spec/Body/WiperSystem.vspec by @Herrmann-Alexander in Correction of typo in spec/Body/WiperSystem.vspec #807
• Missing "s" in vehicle_signal_specification/docs-gen/content/rule_set… by @Herrmann-Alexander in Missing "s" in vehicle_signal_specification/docs-gen/content/rule_set… #811
• Improve instance documentation by @erikbosch in Improve instance documentation #809
• VSS Extension Profile Documentation by @erikbosch in VSS Extension Profile Documentation #817
• VISS documentation update by @UlfBj in VISS documentation update #823
• Fix typo in build check by @erikbosch in Fix typo in build check #825
• Removing some recently added motion management signals. by @erikbosch in Removing some recently added motion management signals. #831

[SebastianSchildt]

Question @erikbosch Now we do have the ObstacleDetection instances in? Anybody has any opinion whteher this is "fine" or should rather be for 6.0?

[erikbosch]

Question @erikbosch Now we do have the ObstacleDetection instances in? Anybody has any opinion whteher this is "fine" or should rather be for 6.0?

This was discussed at the VSS meeting June 24th https://wiki.covesa.global/display/WIK4/VSS+Meeting+Topics+and+Meeting+Notes Conclusion at that time was that it is OK, even if it can be considered as backward incompatible as it seems no-one is using the current signal.

[slawr]

Question @erikbosch Now we do have the ObstacleDetection instances in? Anybody has any opinion whteher this is "fine" or should rather be for 6.0?

Do we have a governance playbook that provides some guidance that would make that some what of a mechanical operation? e.g. How long to report deprecation before a merge, migration note etc. As VSS gains adoption the downstream eco-system is going to get larger and not everyone is going to be monitoring upstream closely.

If we don't have a playbook, then it is something we could consider to add to task backlog. Codifying a summary would be a start.

On the actual question, is the default policy breakage means major number change?

[erikbosch]

We have some definitions i https://covesa.github.io/vehicle_signal_specification/governance/index.html

In short - breaking changes should typically occur only in major releases, indicated by changing the major number. But the devil lies in the details, strictly speaking there are a few changes in the current master branch that can be considered as major:

• GraphQL generator has been refactored, so output is significantly different compared to vss-tools 5.0
• ObstacleDetection instances have refactored instance representation
• The VIN signal has an added pattern. This means that VSS "master" cannot be used used with vss-tools 5.0 in strict mode unless you add an argument to accept the pattern extended attribute. (If you would use vss-tools from "master" there is no problem)

Strictly speaking they are all major changes, so the interesting question here is if we think there are reasonable reasons to anyway treat them as "minor" changes, which could be the following assumptions:

• No one uses the "old" GraphQL tool
• No one uses the current obstacle signals
• We do not consider VSS changes backward incompatible if they can be "solved" by using the latest "matching" minor release of vss-tools.

So maybe it is good to refine when/how/if it is OK to treat a major change as minor.

[Kostadin-Ivanov]

Hello Erik (@erikbosch),
Good observation :)
I agree with you and personally, I think that all of the listed updates might push VSS to 6.0.0

Reason is that we have an "exporter" updates + VSS structure updates for the obstacle signals and VIN - regExp validation pattern.

With regards to VIN - pattern, as far as I remember, there was some updates in the VSS-Tools so to handle the NEW: pattern signal attribute.

Thus, for consistency I'd say that it would depend on both VSS and VSS-Tools versions. If VSS-Tools goes with a major version increase due to some updates requested to handle changes in VSS, then VSS would also have to go 1 major version increase and vice versa.

Just a side question.
Since we currently are on VSS: 5.0, then the new version would be either: 5.1 or 6.0, depending on which versions increment we will pick, right?

For me, both seem OK.

[erikbosch]

If we decide that some items to be considered major, then the workflow would likely be to just cherry-pick those items that not are major to release a minor version. Previously we have said that we do not want to release major version too often, as we want major version to also include significant improvements, not only a type/unit change for a specific signal or similar.

[erikbosch]

From the discussion at the VSS meeting yesterday where people seem to prefer a strict approach I have created https://github.com/COVESA/vehicle_signal_specification/releases/tag/v5.1rc1

This one:

• Include new signals for vehicle motion management and seats
• Does not include pattern or change of instances for obstacles
• Does not update vss-tools, i.e. still use 5.0

The reason for the latter is that we have done some backward incompatible changes on vss-tools master, like removing the --uuid argument. As we have also done quite some other changes just reverting that commit or cherry-picking others would be non-trivial I think. So I suggest waiting with releasing new tools until 6.0

[Kostadin-Ivanov]

If we decide that some items to be considered major, then the workflow would likely be to just cherry-pick those items that not are major to release a minor version. Previously we have said that we do not want to release major version too often, as we want major version to also include significant improvements, not only a type/unit change for a specific signal or similar.

Then, I guess the answer on the whether to go major or minor is very easy :)

Happy VSS 5.1 :)

[erikbosch]

Closing this one as we are preparing the last release for 2025, see https://github.com/COVESA/vehicle_signal_specification/releases/tag/v6.0rc1 and #874