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

   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



[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?


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.



[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

    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 [mailto:thanh...@linuxfoundation.org]
    *Sent:* viernes, 14 de octubre de 2016 4:37
    *To:* sfc-dev@lists.opendaylight.org
    <mailto: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:


    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


    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 versions.


    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

    rele...@lists.opendaylight.org <mailto:rele...@lists.opendaylight.org>


sfc-dev mailing list

Reply via email to