There are multiple subjects:
- the use of HF distributions,
- the set of the "-HF*" pattern,
- the target compliance for maintenance packages.
I guess you're addressing the question backwards:
Review sample Nuxeo Package configuration to ease up install on HF distributions
Install on HF distributions is not a covered usage. That can be discussed and implemented but for now, there's no reason to ease up a bad practice, even less to show it in the samples.
=> If you have a legitimate use case, please describe it. Then we'll be able to work on making those distributions usable.
There's already a JIRA ticket handling that subject: NXP-14085 - Make the MP system usable with "hotfixed distribution"
Once/if implemented, the solution must work without any change in the current assemblies.
About a Nuxeo Package requiring a Hotfix Package, please read NXDOC/Package Manifest.
The use of the "HF-" pattern was a solution to avoid hardcoding the HF compliance in the Java code at a time when there was no valid use case for a HF distribution. That can be reviewed if all the packages now have to mention both "cap-@DISTRIB_VERSION@" and "cap-@DISTRIB_VERSION@-HF" targets.
As you highlighted:
- the target on the SNAPSHOT version are not really accurate, it will become accurate once released:
"cap-8.1-SNAPSHOT, cap-8.1-SNAPSHOT-HF*" => "cap-8.1, cap-8.1-HF*"
- the target on maintenance branches must be reviewed after branch creation, hardcoding the release reference:
"cap-@DISTRIB_VERSION@" and "cap-@DISTRIB_VERSION@-HF*" => "cap-7.10, cap-7.10-HF*" instead of "cap-7.10-HF02-SNAPSHOT, cap-7.10-HF02-SNAPSHOT-HF*"
<< As a result, it's quite difficult to install a SNAPSHOT package on a SNAPSHOT (HF or not) distribution, even if this produces valid configurations at release time (not HF releases, other releases) >>
You described a "wrong" development use case (nuxeo-drive). The install of a SNAPSHOT package on a SNAPSHOT distribution works fine (see 3d below).
Let's look at the known use cases during the 8.1 development cycle:
- |
- |
a |
b |
c |
d |
- |
- |
release distribution
7.10 |
development distribution
8.1-SNAPSHOT |
hotfix distribution
7.10-HF02 |
maintenance distribution
7.10-HF02-SNAPSHOT |
1 |
release package (1.0)
cap-7.10, cap-7.10-HF* |
OK |
NA |
OK |
OK |
2 |
development package (1.1-SNAPSHOT)
cap-8.1-SNAPSHOT, ... |
NA |
OK |
NA |
NA |
3 |
maintenance package (1.0-SNAPSHOT)
cap-7.10-HF02-SNAPSHOT, ... |
KO |
NA |
KO |
OK |
4 |
maintenance package (1.0-SNAPSHOT)
cap-7.10, cap-7.10-HF* |
OK |
NA |
OK |
OK |
Case 3a may be an issue but most of the time the package would not work, missing the HF01 changes (and sometimes also the HF02-SNAPSHOT changes).
Case 3c is not an issue while we do not support the hotfix distributions and don't have a valid use case for that.
So, the current implementation covers all the known use cases (production, development, continuous integration).
4) A slight improvement on the release process would additionally cover the potentially legitimate use case 4a plus the controversial hotfix case 4c.
Since it's rarely needed, it is currently manually done: this requires only one simple change on maintenance branch creation:
- <platform>cap-@DISTRIB_VERSION@</platform>
- <platform>cap-@DISTRIB_VERSION@-HF*</platform>
+ <platform>cap-7.10</platform>
+ <platform>cap-7.10-HF*</platform>
That can/should be automated. It should be easy to replace @DISTRIB_VERSION@ with 7.10 (the release value).
We can even still introduce a nuxeo.target.version property, equal to ${nuxeo.distribution.version} during dev and to the release version during maintenance, which would keep the assembly unchanged and nicely bring back the version management in the POM:
- <filter token="DISTRIB_VERSION" value="${nuxeo.distribution.version}" />
+ <filter token="DISTRIB_VERSION" value="${target.distribution.version}" />
+ <properties>
+ <target.distribution.version>${nuxeo.distribution.version}</target.distribution.version>
+ </properties>
About your solution:
- <filter token="DISTRIB_VERSION" value="${nuxeo.distribution.version}" />
+ <filter token="DISTRIB_VERSION" value="${package.target.version}" />
+ <filter token="SNAPSHOT_SUFFIX" value="${package.snapshot.suffix}" />
- <platform>cap-@DISTRIB_VERSION@</platform>
- <platform>cap-@DISTRIB_VERSION@-HF*</platform>
+ <platform>cap-@DISTRIB_VERSION@@SNAPSHOT_SUFFIX@</platform>
+ <platform>cap-@DISTRIB_VERSION@-HF*@SNAPSHOT_SUFFIX@</platform>
+ <properties>
+ <package.target.version>7.10</package.target.version>
+ <package.snapshot.suffix>-SNAPSHOT</package.snapshot.suffix>
+ </properties>
This also needs to be done on maintenance branch creation but seems harder to automate because of the version split.
There are multiple subjects:
I guess you're addressing the question backwards:
Install on HF distributions is not a covered usage. That can be discussed and implemented but for now, there's no reason to ease up a bad practice, even less to show it in the samples.
=> If you have a legitimate use case, please describe it. Then we'll be able to work on making those distributions usable.
There's already a JIRA ticket handling that subject: NXP-14085 - Make the MP system usable with "hotfixed distribution"
Once/if implemented, the solution must work without any change in the current assemblies.
About a Nuxeo Package requiring a Hotfix Package, please read NXDOC/Package Manifest.
The use of the "HF-" pattern was a solution to avoid hardcoding the HF compliance in the Java code at a time when there was no valid use case for a HF distribution. That can be reviewed if all the packages now have to mention both "cap-@DISTRIB_VERSION@" and "cap-@DISTRIB_VERSION@-HF" targets.
As you highlighted:
"cap-8.1-SNAPSHOT, cap-8.1-SNAPSHOT-HF*" => "cap-8.1, cap-8.1-HF*"
"cap-@DISTRIB_VERSION@" and "cap-@DISTRIB_VERSION@-HF*" => "cap-7.10, cap-7.10-HF*" instead of "cap-7.10-HF02-SNAPSHOT, cap-7.10-HF02-SNAPSHOT-HF*"
<< As a result, it's quite difficult to install a SNAPSHOT package on a SNAPSHOT (HF or not) distribution, even if this produces valid configurations at release time (not HF releases, other releases) >>
You described a "wrong" development use case (nuxeo-drive). The install of a SNAPSHOT package on a SNAPSHOT distribution works fine (see 3d below).
Let's look at the known use cases during the 8.1 development cycle:
7.10
8.1-SNAPSHOT
7.10-HF02
7.10-HF02-SNAPSHOT
cap-7.10, cap-7.10-HF*
cap-8.1-SNAPSHOT, ...
cap-7.10-HF02-SNAPSHOT, ...
cap-7.10, cap-7.10-HF*
Case 3a may be an issue but most of the time the package would not work, missing the HF01 changes (and sometimes also the HF02-SNAPSHOT changes).
Case 3c is not an issue while we do not support the hotfix distributions and don't have a valid use case for that.
So, the current implementation covers all the known use cases (production, development, continuous integration).
4) A slight improvement on the release process would additionally cover the potentially legitimate use case 4a plus the controversial hotfix case 4c.
Since it's rarely needed, it is currently manually done: this requires only one simple change on maintenance branch creation:
That can/should be automated. It should be easy to replace @DISTRIB_VERSION@ with 7.10 (the release value).
We can even still introduce a nuxeo.target.version property, equal to ${nuxeo.distribution.version} during dev and to the release version during maintenance, which would keep the assembly unchanged and nicely bring back the version management in the POM:
About your solution:
This also needs to be done on maintenance branch creation but seems harder to automate because of the version split.