Hi Carsten,
yes indeed I see 
https://github.com/apache/sling-org-apache-sling-repoinit-parser/blob/473d8b976c8d4c9c3a01bdc70e501c7a74b1959b/bnd.bnd#L4
 
<https://github.com/apache/sling-org-apache-sling-repoinit-parser/blob/473d8b976c8d4c9c3a01bdc70e501c7a74b1959b/bnd.bnd#L4>
 and the related ticket https://issues.apache.org/jira/browse/SLING-9186 
<https://issues.apache.org/jira/browse/SLING-9186>.
But what is IMHO missing is:
- Documentation of language version with each added feature listed
- Required minimum language version statement

I am gonna create tickets for those and start working on the documentation 
piece.
Konrad


> On 8. Feb 2021, at 16:48, Carsten Ziegeler <[email protected]> wrote:
> 
> Hi
> 
> didn't we add a provide capability to the parser bundle which versions the 
> language?
> 
> Keep in mind that repoinit might be aggregated, for example through the 
> feature model and each individual feature file might define a different 
> minimum version.
> 
> So if we add a version statement to the language, it either defines the 
> version for the following block of commands (until another version statement 
> appears), or the aggregation of repoinit needs to be more clever taking the 
> new version statement into account.
> 
> Regards
> Carsten
> 
> Am 04.02.2021 um 18:48 schrieb Konrad Windszus:
>> Hi
>> The documentation at 
>> https://sling.apache.org/documentation/bundles/repository-initialization.html
>>  does not state which features are supported since which version of the 
>> language (in fact it only documents supported features in 1.0.2). What 
>> happens if I use a non-supported feature with an older repoinit parser?
>> For example if I use the "with path" clause 
>> (https://issues.apache.org/jira/browse/SLING-7226) with repoinit.parser 
>> 1.1.0? My assumption (not yet verified) is that it will just throw an 
>> exception.
>> Would it make sense to version the repoinit language semantically and put 
>> the required version into the repoinit statements (as first line). That way 
>> one could (at least for future) bail out of processing repoinit statements 
>> which are not yet supported with a proper exception (or optionally just skip 
>> those).
>> Thanks in advance for your input,
>> Konrad
> 
> -- 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> [email protected]

Reply via email to