camunda / element-templates-json-schema

JSON Schema for (Camunda) Element Templates
10 stars 7 forks source link

Make the version property mandatory #101

Closed sbuettner closed 1 year ago

sbuettner commented 1 year ago

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.

nikku commented 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.

sbuettner commented 1 year ago

@nikku Thanks for the heads up.

Wouldnt a new mandatory property be possible in general by adding another schema version?

sbuettner commented 1 year ago

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/

nikku commented 1 year ago

I believe this is a matter of user enablement through documentation. Our Camunda documentation can be improved in a number of ways:

nikku commented 1 year ago

I'll close this issue for the reasons stated. Let's work together to get versioning:

nikku commented 1 year ago

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.

sbuettner commented 1 year ago

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.

nikku commented 1 year ago

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.

sbuettner commented 1 year ago

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.

nikku commented 1 year ago

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: