Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 471732

Summary:	Should we update non-delivered artifacts to reflect service version?
Product:	[Eclipse Project] Platform	Reporter:	David Williams <david_williams>
Component:	Releng	Assignee:	David Williams <david_williams>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	arunkumar.thondapu, igor, jan.sievers, markus.kell.r, mikael.barbero
Version:	4.5
Target Milestone:	4.5.1
Hardware:	PC
OS:	Linux
Whiteboard:
Bug Depends on:	469765
Bug Blocks:

Description David Williams

2015-07-02 14:06:44 EDT

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?

Comment 1 David Williams

2015-07-02 14:08:41 EDT

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?

Comment 2 Jan Sievers

2015-07-03 03:19:47 EDT

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

Comment 3 David Williams

2015-07-08 02:01:57 EDT

Decision was made to branch everything, and update all "parent pom's" to service level. 

Thanks for your comments.