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; rele...@lists.opendaylight.org;
Miguel Angel Muñoz Gonzalez <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
https://lists.opendaylight.org/mailman/listinfo/release
_______________________________________________
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
