Done. A patch has just been submitted to hardcode the value temporarily until 
it is decided what to do with the version numbers.

Btw, I just realized that changing from 0.4.x to 0.5.0 can be performed with 
the kind features we will be introducing in SFC in this release since the major 
number will still be '0'. It does not matter if we are introducing backward 
incompatible changes or not, correct?

Miguel Ángel.

From: Brady Allen Johnson
Sent: viernes, 14 de octubre de 2016 10:13
To: Miguel Angel Muñoz Gonzalez <>; 
Thanh Ha <>;;
Subject: Re: [release] Version conflict introduced in sfc-ui-module

Thanks Miguel.

Thanh, we made this change because we were trying to solve the warning in this 
email [0]. Im open to the best solution to solve those warnings, but to also 
follow ODL best practices.

As a quick fix to unblock the current problems, and until we come up with a 
long-term fix, we'll go ahead and hard-code the version to 0.5.0-SNAPSHOT.




On 14/10/16 07:53, Miguel Angel Muñoz Gonzalez wrote:
Hi Thanh, all,
 If it is allowed to increase versions at the moment in SFC and inheriting 
properties from parent seems to be a good practice,  bumping all the sfc 
versions to a higher number sounds like a good alternative. However, my concern 
is that we will be changing major/minor numbers and I'm not sure if we 
introduced incompatible changes in SFC to justify such increase (according to 
semantic versioning).

If there are not incompatible changes in SFC I guess we would have to stick to 
option 2) and hardcode 0.5.0 into the sfc-ui-module.


Miguel Ángel.
From: Thanh Ha []
Sent: viernes, 14 de octubre de 2016 4:37
To:<>;<>; Miguel 
Angel Muñoz Gonzalez 
Subject: Version conflict introduced in sfc-ui-module

Hi Everyone,

I think we have a blocker issue as I've just noticed this patch was merged:

and will actually prevent us from releasing Carbon in the future since the 
version of  sfc-ui-module that's currently set is already been released.

The problem with this patch is that ${dlux.version} is configured as:


While sfc-parent version was:

Boron = 0.3.x-SNAPSHOT
Carbon = 0.4.x-SNAPSHOT

So the patch in Carbon downgraded sfc-ui-module's version to 0.4.x-SNAPSHOT 
which was already released:

(Also I think it's bad practice to make a newer version of your software have 
the same version as the previous released version)

The problem with the patch is that when the version number in a pom file is 
omitted it takes the version number of the parent pom that is declared in said 
pom file. I think there's a couple possible solutions to this.


If SFC really wants to start using the parent pom's version for all their maven 
modules than we need to bump the sfc-parent pom version to a high enough 
version that it doesn't cause any modules that are using it to reduce their own 


Alternatively if SFC does not want to use ${dlux.version} because it causes a 
maven warning. Than we need to hardcode the version 0.5.0-SNAPSHOT in the 
sfc-ui-module pom file.



release mailing list<>

sfc-dev mailing list

Reply via email to