You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Radu Cotescu <ra...@apache.org> on 2018/01/18 17:19:00 UTC
[proposal] HTL modules versioning scheme
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
Re: [proposal] HTL modules versioning scheme
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jan 19, 2018 at 10:15 AM, Radu Cotescu <ra...@apache.org> wrote:
> ...The goal
> here was to figure out from the artifact file name what specification
> version it supports....
Ok, works for me!
-Bertrand
Re: [proposal] HTL modules versioning scheme
Posted by Radu Cotescu <ra...@apache.org>.
Hi Bertrand,
We already expose a bundle header - I wouldn't add another one. The goal
here was to figure out from the artifact file name what specification
version it supports.
Thanks,
Radu
On Thu, 18 Jan 2018 at 19:13 Bertrand Delacretaz <bd...@apache.org>
wrote:
> Which could be handled with custom bundle headers like X-HTL-Version,
> isn't it?
> Maybe processed by a webconsole plugin.
>
> Instead of dummy bundle version upgrades.
>
Re: [proposal] HTL modules versioning scheme
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jan 18, 2018 at 6:29 PM, Konrad Windszus <ko...@gmx.de> wrote:
> 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...
Which could be handled with custom bundle headers like X-HTL-Version, isn't it?
Maybe processed by a webconsole plugin.
Instead of dummy bundle version upgrades.
-Bertramd
Re: [proposal] HTL modules versioning scheme
Posted by Konrad Windszus <ko...@gmx.de>.
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 <ra...@apache.org> 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
Re: [proposal] HTL modules versioning scheme
Posted by Radu Cotescu <ra...@apache.org>.
Hi Robert,
I think this is the best compromise. Thanks for the idea!
Radu
On Fri, 19 Jan 2018 at 08:58 Robert Munteanu <ro...@apache.org> wrote:
> How about doing it the other way around - <module_version>-
> <specification_version>?
>
Re: [proposal] HTL modules versioning scheme
Posted by Robert Munteanu <ro...@apache.org>.
Hi Radu,
On Thu, 2018-01-18 at 17:19 +0000, Radu Cotescu 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>
How about doing it the other way around - <module_version>-
<specification_version>?
This way the versioning refers to the module's evolution, not to the
spec, and it's also clear what spec version it implements.
Thanks,
Robert
Re: [proposal] HTL modules versioning scheme
Posted by Radu Cotescu <ra...@apache.org>.
Hello Oliver,
The ScriptEngineFactory already exposes this info. I just want to be able
to figure out the spec version from the module's file name. In the end I
will go with Robert's proposal.
The way HTL is implemented right now is that we have front-end and back-end
compilers (which are Sling API independent), and then there's the Script
Engine module that glues everything into Sling's platform, which is why,
IMO, the info about which specification is supported should be present in
all modules in a way or another.
Cheers,
Radu
On Fri, 19 Jan 2018 at 10:24 Oliver Lietz <ap...@oliverlietz.de> wrote:
>
>
> that is not quite correct. The language version is exposed by the
> ScriptEngineFactory (JSR 223).
>
> I would not couple bundle version to language version at all (it's fine to
> have multiple engines per bundle, e.g. one for 1.x and another for 2.x).
>
> Regards,
> O.
>
Re: [proposal] HTL modules versioning scheme
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Thursday 18 January 2018 17:19:00 Radu Cotescu wrote:
> Hello,
Hi,
> 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.
that is not quite correct. The language version is exposed by the
ScriptEngineFactory (JSR 223).
> 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.
I would not couple bundle version to language version at all (it's fine to
have multiple engines per bundle, e.g. one for 1.x and another for 2.x).
Regards,
O.
> Thanks,
> Radu
>
> [0] -
> https://github.com/Adobe-Marketing-Cloud/htl-spec/blob/1.3.1/SPECIFICATION.m
> d