[CAM-12666] Clearly define a versioning strategy for the archetypes repository - camunda JIRA

We should establish and document a clear versioning strategy for the archetypes repository.

Proposal:

Separate versioning, starting at 1.0.0
each major version of archetypes is compatible with Camunda BPM minor (1.x => 7.14)
content changes on archetypes within the Camunda BPM minor are minor version updates of the archetypes (1.1.x => 7.14 with content changes in archetypes)
with the release of 7.15, we will create 2.x of the archetypes
new content changes will go into 2.1.x afterwards and CAN be backported to 1.2.x if necessary (being compliant with 7.14)

Open questions:

What about EE patches if a new Archetype version is needed (e.g. if webapps paths change and a new archetype is needed built on EE patch level like 7.14.1)?

We should establish and document a clear versioning strategy for the archetypes repository.

Proposal:

Separate versioning, starting at 1.0.0
each major version of archetypes is compatible with Camunda BPM minor (1.x => 7.14)
content changes on archetypes within the Camunda BPM minor are minor version updates of the archetypes (1.1.x => 7.14 with content changes in archetypes)
with the release of 7.15, we will create 2.x of the archetypes
new content changes will go into 2.1.x afterwards and CAN be backported to 1.2.x if necessary (being compliant with 7.14)

Open questions:

What about EE patches if a new Archetype version is needed (e.g. if webapps paths change and a new archetype is needed built on EE patch level like 7.14.1)?