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. Opinions? Miguel Ángel. From: Thanh Ha [mailto:[email protected]] Sent: viernes, 14 de octubre de 2016 4:37 To: [email protected]; [email protected]; Miguel Angel Muñoz Gonzalez <[email protected]> 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: https://git.opendaylight.org/gerrit/46730 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: BORON = 0.4.x-SNAPSHOT CARBON = 0.5.x-SNAPSHOT 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: https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/sfc/sfc-ui-module/ (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. 1) 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 versions. 2) 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. Thanh
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
