-
Type: Improvement
-
Status: Open
-
Priority: Minor
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: QualifiedToSchedule
-
Component/s: Dev Tools
While the use of version range is strongly discouraged, there are cases where it can be useful, if not required.
Using the version range requires being able to fix the version when releasing.
JAVACLIENT-191 shew that release.py --also-replace-version option currently fails on version range parsing:
nuxeo-java-client (master $ u= origin/=)$ release.py nop --arv='[11.0,12.0)/11.1-SNAPSHOT' --dryrun DEBUG -- init Release with: DEBUG: other_versions=[11.0,12.0)/11.1-SNAPSHOT ... [ERROR] Could not parse other_versions parameter '[11.0,12.0)/11.1-SNAPSHOT'.
This range (used to test the latest distribution) is not an issue during CI but during the release, it resolves to unwanted and undetermined versions (such as a staging datebased for instance).
TODO:
- fix the version range parsing to allow replacement before and after release
- bonus: improve the --arv option to allow restricting the replacement to a given property
- current global pattern:
[<files pattern>]:[<properties pattern>]:[<version replacement pattern>]
- current global pattern:
-
- the version replacement pattern itself being:
<old>/<new>[/next][,...]
- the version replacement pattern itself being:
-
- the version replacement pattern could be like:
<old>/<new>[/next]=<target>[,...] or <target>=<old>/<new>[/next][,...]
with <target> being files or properties patterns.
- the version replacement pattern could be like: