Could we allow minor changes to previous editions?

[e-backmark-ericsson]

Description

How could we handle patches to an old edition of the protocol? With the current one-track approach I see no simple way to perform such patches. Stepping from one edition of the protocol to the next could incorporate big changes for the users of the protocol (e.g. #195). Could we document a way to handle patches to old editions or event versions, or should we strictly forbid such patches? When an event has changed from say 2.1.0 to 3.0.0, could it still be possible to release version 2.2.0 of that event?

Motivation

The need to patch an old edition will come sooner or later. We need to document whether that is possible or not, and how it could be done.

Exemplification

An eco system of tools implemented for the Toulouse edition might be very expensive and time consuming to lift to the next edition, containing for example #195. Patches on top of Toulouse might be needed before such a protocol lift can be deployed.

Benefits

When the need comes we have a prepared way to handle it.

Possible Drawbacks

Unnecessary complex branching structure and unneeded documentation if such patches will never be needed.

[vasile-baluta]

We could create a new repository from a given point of the main track when needed. That will be a first patch and subsequent patches for that version will be done on this repository.

Another alternative is to create a branch in the same repository.

[d-stahl-ericsson]

Regardless of protocol versioning policy, all versions of an event need to be maintained in the same branch of the same repository. Otherwise you'll get conflicts, where event types have different sets of recognized versions depending on which branch/repository/variant of the protocol you adhere to. Even worse, the same version of the same event type may look different in the various forks.

There's nothing in principle that says you can't release 2.2.0 after a 3.0.0: the version numbers represent compatibility, not chronology. So as long as you don't violate the versioning rules, you can "patch" past editions (or more to the point, past event types) all you like. There are caveats, though:

• You'll be bound by backwards compatibility. If you want to make ANOTHER backwards incompatible change to 2.1.0 AFTER 3.0.0 has been introduced, that will have to become 4.0.0, which, if it represents an evolutionary side-track will be really weird. I guess the easiest way is to establish a rule: Don't do that!
• While the event type versioning is relatively straight-forward, we need to establish how to manage editions. What do we call the "Improved Toulouse" editions? "Toulouse-1", "Toulouse-2"...?

[d-stahl-ericsson]

By the way, once we reach some conclusion I suggest we include that in PR #196.

[d-stahl-ericsson]

Where are we on this? Should I update the PR as I suggested?

[e-backmark-ericsson]

Sure, go ahead and update #196 with the ideas in this discussion. It could be a good piece of text to relate to when continuing the discussion in this issue.

[d-stahl-ericsson]

PR updated.