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? BR, Miguel Ángel. From: Brady Allen Johnson Sent: viernes, 14 de octubre de 2016 10:13 To: Miguel Angel Muñoz Gonzalez <miguel.angel.munoz.gonza...@ericsson.com>; Thanh Ha <thanh...@linuxfoundation.org>; sfc-dev@lists.opendaylight.org; rele...@lists.opendaylight.org 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. Regards, Brady [0] https://lists.opendaylight.org/pipermail/sfc-dev/2016-October/003475.html 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. Opinions? Miguel Ángel. From: Thanh Ha [mailto:thanh...@linuxfoundation.org] Sent: viernes, 14 de octubre de 2016 4:37 To: sfc-dev@lists.opendaylight.org<mailto:sfc-dev@lists.opendaylight.org>; rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>; Miguel Angel Muñoz Gonzalez <miguel.angel.munoz.gonza...@ericsson.com><mailto:miguel.angel.munoz.gonza...@ericsson.com> 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 _______________________________________________ release mailing list rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/release
_______________________________________________ sfc-dev mailing list sfc-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/sfc-dev
