The only concern I have with this is that not necessarily each module needs to be updated for each new HTL-Spec. That means that "sightly.js.provider" might still be at 1.3.xx while spec and other modules are already at 1.4.x. Therefore I would rather completely decouple spec version from sightly module version or only use it for the modules which always need to be rereleased for new spec versions. Konrad
> On 18. Jan 2018, at 18:19, Radu Cotescu <[email protected]> wrote: > > Hello, > > This is something I wanted to do for a while, but haven't had the chance. > It's currently a bit difficult to figure out what HTL bundle supports which > HTL language specification version. This information is currently only > present in the Provide-Capability headers that the bundles expose. > > Would you have something against the following versioning scheme for the > HTL-related modules? > > <specification_version>.<module_version> > > The latest specification version is 1.3.1 [0], already implemented by our > modules. > > That would mean that the next releases will be: > > org.apache.sling.scripting.sightly.compiler-1.3.1.0 > org.apache.sling.scripting.sightly.compiler.java-1.3.1.0 > org.apache.sling.scripting.sightly-1.3.1.0 > org.apache.sling.scripting.sightly.js.provider-1.3.1.0 > org.apache.sling.scripting.sightly.models.provider-1.3.1.0 > org.apache.sling.scripting.sightly.testing-1.3.1.0 > org.apache.sling.scripting.sightly.testing-content-1.3.1.0 > htl-maven-plugin-1.3.1.0 > > The org.apache.sling.scripting.sightly.repl module is independent from the > HTL specification and can use its current versioning scheme. > > I would also adjust the JIRA versions accordingly. > > Thanks, > Radu > > [0] - > https://github.com/Adobe-Marketing-Cloud/htl-spec/blob/1.3.1/SPECIFICATION.md
