Community
Participate
Working Groups
I'm opening this bug as a corollary of bug 469765. In the past, when we switched to "maintenance builds" we left parent pom, and others, with the same version as the main release (such as 4.4.0, instead of changing to 4.4.1). (There are few that have to be updated ... such as for "products"). For purposes of producing our builds and main deliverables this works fine. But, I've always heard it is more "the maven way" to update to reflect the service version that is being worked on or produced. What I'm curious about, is if there are any use-cases (in the community of users) that would benefit from following more the "maven way". If nothing concrete, then it is easier for our platform committers just to leave as is. (But, we are getting more experienced with pom's, so not as bad as it might have been in the past). The purpose of this bug is to discuss and eventually decide if there is a reason to do it for our "4.5.1" work?
Adding some maven/tycho experts to CC, to get advice, or if they know of any known use-cases that would benefit from following the stricter maven custom of versioning things like parent pom, according to service version?
short version: yes it's recommended to change versions on patch branches. long version: first of all, at maven's core is the concept of SNAPSHOT versions vs released versions. - SNAPSHOT versions (ending with -SNAPSHOT) are used during development and expected to be constantly changing and ephemeral - released versions (not ending with -SNAPSHOT) are *immutable* i.e. they are never expected to change. E.g. once downloaded (or 'mvn install'-ed) to the local maven repo cache, maven will never check for updates from a remote maven repo of a released version since it is immutable. A common versioning strategy for maven projects is development - 1.0.0-SNAPSHOT release - 1.0.0 development - 1.1.0-SNAPSHOT (or 2.0.0-SNAPSHOT) . . . dev on patch branch - 1.0.1-SNAPSHOT patch release - 1.0.1 dev on patch branch - 1.0.2-SNAPSHOT . . . if you want to isolate patch branch development from master branch development, it's a good idea to version the parent so it is distinct from the version of the master branch (as it has wide impact on the whole build). Now I know you are not doing a release in the maven sense for plugins/features as they always use -SNAPSHOT and these are kept reproducible using [1] instead. For the parent poms however I would recommend versioning similar to outlined above (even if you skip the release part, changing the version on the patch branch to reflect it's patch development is a good idea). All of this gets really important if the parent is referenced from remote (and not built locally). In this case proper and distinct versioning is mandatory otherwise you will mix master and patch branch changes/released versions may not get updated if changed. [1] https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers
Decision was made to branch everything, and update all "parent pom's" to service level. Thanks for your comments.
