Implements version label should display what the current version (build) #1453
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes OHDSI/Atlas#1910
Implementing the version display requires some additional rules of naming conventions.
I'd like to propose the following rules:
The similar rules are used by the Spring team.
Milestone issues and release notes links
There was 4 additional options added to the pom.xml.
<buildinfo.atlas.milestone.id>22</buildinfo.atlas.milestone.id>
<buildinfo.webapi.milestone.id>25</buildinfo.webapi.milestone.id>
<buildinfo.atlas.release.tag>*</buildinfo.atlas.release.tag>
<buildinfo.webapi.release.tag>*</buildinfo.webapi.release.tag>
They point milestone id and release tag for Atlas and WebAPI repositories.
For development and release candidate builds which has no release the
release.tag
value should be an asterisk (*) since spring-boot-maven-plugin doesn't allow null values. For a release build the release.tag should be the release tag name as it created on the github (it's case sensitive). This allows making a direct link to the release notes of the proper version rather than a link to the whole release notes list.Additionally name of the branch and commit id from where a build was assembled are included to the build info available by the
WebAPI/info
. This should provide to answer the frequent questions like theis this issue included in the build
. And the life of people should be a little easier.