Use semantic versioning?

[plajjan]

ncclient is used in a project I'm involved in and has multiple times broken builds due to backwards incompatible version. Latest was from 0.6.7 to 0.6.8.

Major version 0 is sort of reserved and roughly equates to "anything goes".. but while comfortable from a ncclient perspective, it is quite a terrible promise to users. As a user of this library, I want to be able to rely on it and not be constantly (negatively) surprised by new versions. I want patch releases to fix bugs in a backwards compatible fashion and backwards incompatible changes to go into new major versions.

I'm not sure if ncclient feels it isn't mature enough for a 1.0 release and trying to adhere to semantic versioning, but I do think it would be nice for its users.

[plajjan]

Heh, so the change in question is #416 - opened by someone who is also working on the same project I mentioned ;)

Changing args is backwards incompatible and should go in a new major version.

[einarnn]

The backwards incompatible change was unintentional and due to a bad code review on my part. The 0.6.8 release has been yanked and, once the issue is resolved, a 0.6.9 will be introduced.

I don't think ncclient is ready for a 1.0.0 version as yet, but if there are other opinions, I'm open to it.

[plajjan]

Thanks @einarnn!

What do you think would make ncclient ready for a 1.0? Not trying to be a PITA here, just want to avoid "1.never" ;)

[einarnn]

@plajjan, I would never say you're being a PITA! Well, at least not without plausible deniability!

More seriously, here's a few things I think may be the minimum we should address before calling a 1.0:

• Asyncio support (#225, maybe other issues)
• Reviewing protocol support to ensure that, for example, TLS support could be introduced without major disruption
  • Motivation here is that I've had a few enquiries about TLS support
• Introduce testing targeted at trying to ensure APIs are kept backwards compatible
  • As part of this, getting testing code coverage above 80% would be highly desirable
• Scrub the issue tracker:
  • Of particular concern (reverse chronological order):

    • 394

    • 371

    • 256

    • 252

    • 230

  • Decide the disposition of most of the rest of the open issues (e.g. "unreproducible", "enhancement", etc...)

Interested in your opinions on what else may need to be addressed before we could call a 1.0?

Cheers,

Einar

[plajjan]

Heh, thanks :)

I'm not sure I think any of those are really necessary for a 1.0, Like, I get that they might require major changes but that's fine. Major changes are allowed going between major versions. If asyncio requires a major change then it'll mean we go from 1.x to 2.x...and that's a good thing. No problem.

Same for all the other issues you mention. I don't think any of them are really of the caliber that it would prevent that pretty much the current state of ncclient becomes a 1.0 and that we then progress from there.

The issues you link of particular concern might be important (I don't contest that) but ISTM that they are mostly not about API changes - they are simply bug fixes and won't require changing any interface, thus, they can be done as 1.0.1, 1.0.2 etc.

Releasing a 1.0 would mean users could pin something in their requirements.txt, which I think would be very welcome amongst a lot of users!

It is perfectly fine (in a semver world) doing backwards incompatible changes between major versions.

[einarnn]

I'll put aside some time to consider this in more detail. Thanks for the feedback!