Re: [proposal] HTL modules versioning scheme

[Radu Cotescu]

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  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

[Oliver Lietz]

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?
> 
> .
> 
> 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

Re: [proposal] HTL modules versioning scheme

[Bertrand Delacretaz]

On Fri, Jan 19, 2018 at 10:15 AM, Radu Cotescu  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

[Radu Cotescu]

Hi Robert,

I think this is the best compromise. Thanks for the idea!

Radu

On Fri, 19 Jan 2018 at 08:58 Robert Munteanu  wrote:

> How about doing it the other way around - -
> ?
>

Re: [proposal] HTL modules versioning scheme

[Radu Cotescu]

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 
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

[Robert Munteanu]

Hi Radu,

On Thu, 2018-01-18 at 17:19 +, 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?
> 
> .

How about doing it the other way around - -
?

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

[Bertrand Delacretaz]

On Thu, Jan 18, 2018 at 6:29 PM, Konrad Windszus  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

[Konrad Windszus]

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  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?
> 
> .
> 
> 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

[proposal] HTL modules versioning scheme

[Radu Cotescu]

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?

.

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