Sorry. Let me try again.

The semver definition seems to say that backend changes that don't change
the API, still should have the patch version increased.

> Bug fixes not affecting the API increment the patch version

New features would either be backward compatible with the API or not,
therefore incrementing the major, minor, or patch version.

That seems to me to make the need for the plugin version to be redundant.
Yes?

On Sat, May 25, 2019 at 8:03 AM Damjan Marion via Lists.Fd.Io <dmarion=
me....@lists.fd.io> wrote:

>
>
> On 25 May 2019, at 13:43, Paul Vinciguerra <pvi...@vinciconsulting.com>
> wrote:
>
> Hi Damian,
>
> That's what I initially thought as well.  The semver doc says:
>
>  For this system to work, you first need to declare a public API. This may
> consist of documentation or be enforced by the code itself. Regardless, it
> is important that this API be  clear and precise. Once you identify your
> public API, you communicate changes to it with specific increments to your
> version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug
> fixes not affecting the API increment the patch version, backwards
> compatible API additions/changes increment the minor version, and backwards
> incompatible API changes increment the major version.
>
> And their FAQ says:
>
> What should I do if I update my own dependencies without changing the
> public API?
>
> That would be considered compatible since it does not affect the public
> API. Software that explicitly depends on the same dependencies as your
> package should have their own dependency specifications and the author will
> notice any conflicts. Determining whether the change is a patch level or
> minor level modification depends on whether you updated your dependencies
> in order to fix a bug or introduce new functionality. I would usually
> expect additional code for the latter instance, in which case it’s
> obviously a minor level increment.
>
> So I was thinking that the API version alone, the semver, should be
> sufficient, yes?
>
>
> Sorry, i’m not getting what are you trying to say...
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#13147): https://lists.fd.io/g/vpp-dev/message/13147
> Mute This Topic: https://lists.fd.io/mt/31757481/1594641
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [
> pvi...@vinciconsulting.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13150): https://lists.fd.io/g/vpp-dev/message/13150
Mute This Topic: https://lists.fd.io/mt/31757481/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
  • ... Paul Vinciguerra
    • ... Damjan Marion via Lists.Fd.Io
      • ... Paul Vinciguerra
        • ... Damjan Marion via Lists.Fd.Io
          • ... Paul Vinciguerra
            • ... Damjan Marion via Lists.Fd.Io
              • ... Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
                • ... Damjan Marion via Lists.Fd.Io
                • ... Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
              • ... Ole Troan

Reply via email to