Hi All,

We have encountered a behavior of versionStorage and versionLabels which I
think is bug.

*Current behavior:*



   1. Create a node and make it *versionable*
   2. Now create more than two versions (for example two version is  *1.0*
   and *1.1* respectively)
   3. Now add label at version 1.0 via *VersionHistory* Object (for example
   label is *Label_1.0*)
   4. Now remove the version 1.0 via calling *removeVersion(1.0)* method of
   *VersionHistory* object
   5. Now call method *hasVersionLabel(Label_1.0)  *of versionHistory . its
   now returning true.



*Expected behaviour:*

Call to the *hasVersionLabel(Label_1.0)*  of *versionHistory* should not
return true because version associated with label does not exist. And
removing the version should remove associated labels.



If we say that *hasVersionLabel(Label_1.0)*  of *versionHistory* returning
true is expected behavior because label is not removed. Then call to the
function getVersionByLabel(*Label_1.0) of versionHistory* will throw
VersionException because version does not exist. So the repository goes
into inconsistent state.


*Solution proposal:*

One of the solution can be that whenever consumer of  versionHistory
removes the version , he should be forced to remove the versionLabel first
by throwing LabelExistException



Another solution can be we should remove version label whenever user
removes the version.


Current behavior of *versionLabel* node:
1) it keeps mapping of version and labels
2) labels name should be unique for node.

3) one version can have multiple labels



Sample test case is added in patch of jira *OAK-9891*

I want to know what can justify this behavior.


*I want to know what are the thoughts of communities regarding this .*
1) if we agree on bug , what can be best solution from above suggested
approach. Any other suggestions.

2) if we disagree, what is reasoning.


Rerence docs:
https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/15_Versioning.html

[1] https://issues.apache.org/jira/browse/OAK-9891



Thanks,

Arun Kumar Ram

Reply via email to