Closed sbuettner closed 1 year ago
Unfortunately that would be a breaking change, affecting all element templates, and we'll very likely not be able to execute it.
But let us think about it, what would that mandatory version
solve? How would it encourage folks to properly version their templates? People could still add a version=1
property and not update it forever.
As a little bit of background, no version is the first version, and upgrading from unversioned to versioned is a smooth process.
@nikku Thanks for the heads up.
Wouldnt a new mandatory property be possible in general by adding another schema version?
But let us think about it, what would that mandatory version solve? How would it encourage folks to properly version their templates? People could still add a version=1 property and not update it forever.
Which can be fine if its lets say just a description right?
Maybe a general versioning guideline section would help: https://docs.camunda.io/docs/next/components/modeler/desktop-modeler/element-templates/defining-templates/
I believe this is a matter of user enablement through documentation. Our Camunda documentation can be improved in a number of ways:
I'll close this issue for the reasons stated. Let's work together to get versioning:
Maybe as an additional side-note: For managed templates aka connector templates (created, updated and published via web modeler) we handle versioning internally. If we want to keep that as a use-case then it has to be optional.
I believe this is a matter of user enablement through documentation.
I share a different perspective here as an explicit versioning concept educates people way more than requiring to read any documentation especially as there is implicit versioning going on if you dont specify it.
Its still not clear to me why we dont require this as its quite common to specify versions (pom.xml, package.json,...) nowadays for almost any kind of artifact.
For managed templates aka connector templates (created, updated and published via web modeler) we handle versioning internally.
Not sure what you mean here with versioning internally as we explicitly manage and increase versions in case of any changes manually.
For managed templates aka connector templates (created, updated and published via web modeler) we handle versioning internally.
Not sure what you mean here with versioning internally as we explicitly manage and increase versions in case of any changes manually.
If you publish your custom template through web modeler you do not explicitly handle and/or increment the version. Instead web modeler handles versioning behind the scenes as you publish a new version of your template. From the editor perspective this implies that version
has to be optional.
I thought you meant the templates we ship together with the web modeler.
Yes, sure but this also leads to version increases for simple string changes of descriptive fields where customer might not need to "upgrade" usually but will be asked for.
Yes, sure but this also leads to version increases for simple string changes of descriptive fields where customer might not need to "upgrade" usually but will be asked for.
That is correct :slightly_smiling_face:
Is your feature request related to a problem? Please describe
Having a version in an element template is considered best practice. It would be great to always require a version to support consistend upgrade behaviour when making changes to a template.
Describe the solution you'd like
The json schema should require to define a version property for element templates.