In the shared profile versioning, we must consider the analysis patterns and the monitoring rules.
Versioning is enough flexible to adapt to your organization practices. Versioning can rely on both source code management systems – where git is recommended – and internal custom versioning as detailed herafter.
Analysis patterns
Shared libraries and frameworks evolve over time and their analysis patterns – which are issued from the code annotations – should follow.
Versioning of the shared profiles in Jeyzer is left to your decision and is optional.
If you decide to go for it, you have the choice between inheriting from a SCM repository strategy, organizing your own versioning structure of the profiles and/or follow the one introduced with the automatic loading of shared profiles. It’s important to highlight that you can combine the strategies.
Source Code Management versioning
If you follow good practices, your profiles should be managed within a SCM system at the Jeyzer profile repository level.
In such case, the existing SCM versioning strategy can drive the patterns versioning through branches and tags.
Like for pom.xml files in Maven, the version attribute (detailed below) could be set with the current version : official one, snapshot, latest.
Note : There is no Maven release plugin release at this stage to update the Jeyzer pattern versions, but a global search/replace should make it quickly.
The Jeyzer base and demo profile repositories follow the SCM versioning strategy.
Each Jeyzer release triggers the tagging of these repositories : pattern file versions get updated accordingly.
On the master branch, pattern file versions are always set to LATEST.
Custom versioning
In the custom versioning approach, the best is to follow the major version numbering and make it part the shared profile name : profiles/external/shared/myapp-5.0
The master profiles will then reference this myapp-5.0 dependency.
The analysis patterns file will then be named : myapp-5.0_patterns.xml
Reason to go for major version numbering is that method and class signatures could change significantly from one major version to another, and therefore the analysis patterns will be strongly impacted.
The pattern version field (covered below) could be used here as a minor version.
Project based versioning
The automatic loading of shared profiles includes the optional version handling in the profile resolution.
It is based on the standard project.version property (typically on Maven) and requires to follow a certain shared profile naming and naming convention detailed in the automatic loading section.
Analysis pattern version field
Analysis patterns carry a version attribute which can reflect a SCM tag/head version, a minor version or a custom temporary label such as “work in progress”. <profile version="2.1">
This field is optional and has no impact on the analysis : it makes full sense to use it when working primarily with local profiles (you wish to know where you stand).
It is displayed in the Analysis Patterns sheet of the JZR report.
You could set it automatically as part of your build process.
Monitoring rules
Monitoring rules are stored along with the analysis patterns and therefore should follow the same versioning approach (SCM, custom and/or project based).
In the above custom versioning example, the monitoring rules file would be named myapp-5.0_rules.xml.
Monitoring rules are sometimes specific to a minor version : the rule will then get a sticker representing that version (or group of versions).
See the Stickers section for more details.
Generally speaking, Jeyzer is enough flexible to get the monitoring rules applied for any version, a specific version or a set of versions. Each above versioning approach is compatible in this respect.