Ok, so I talked to Stephen Kitt from ODL parent about this, and he said
the following:
That works for me as a long-term fix too, in the current state of
versioning in ODL.
There are two basic rules:
* never decrease a version number
* avoid using variables in version number specifiers (the top-level
version number in POMs)
Effectively the safe way of replacing a property is to hard-code the
corresponding value in place.
Generally speaking I like to have a single version across a repository,
because it means version-based tags can be used meaningfully. There
are workarounds, such as using prefixed version-based tags, so this is
only a "like" as far as I'm concerned. It's hard to enforce in ODL
anyway!
Within ODL, I also like to avoid pulling in a version number from the
parent; I prefer having fully-specified groupId/artifactId/version
information in a POM. In some cases it's redundant, but it avoids
issues when we switch parents, e.g. when moving from a project-specific
parent to an odlparent-provided parent POM.
Semantic versioning specifies the minimum change you need to make to a
version number based on the changes made since the previous release; it
doesn't specify a maximum change. You're always free to bump a version
by more than the semantic requirement.
In addition, semantic versioning makes no claims with regards to 0.x
versions, so it doesn't apply here.
So you could bump all of SFC to 0.5.0-SNAPSHOT, as long as you manage
the required changes to your dependents as well!
So, here's how we will proceed with this:
* I'll merge Miguel's patch [0] to hard code sfc-ui to 0.5.0 to fix
the blocked issues
* I'll inform all of the SFC down-stream projects that we will be
bumping the SFC versions
* Once they're all ready/agreed, we'll submit a patch to do this
Regards,
Brady
[0] https://git.opendaylight.org/gerrit/#/c/46937/
On 14/10/16 10:49, Miguel Angel Muñoz Gonzalez wrote:
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
