Decide to deprecate module level functions?

Situation

Currently, we have mostly functions which are either on the module level (semver.next_version, semver.bump_*) and almost the same on the VersionInfo level (semver.VersionInfo.next_version, semver.VersionInfo.bump_*).

I know, they both serve distinctive purposes: the first expects and returns a string whereas the second needs a VersionInfo object.

However, from an implementation perspective, I’m wondering if this is double work. It looks inefficient to me when the VersionInfo methods need to convert the object first into a string, call the modul level function, and convert it back to a VersionInfo object.

IMHO, we should improve this situation.

Suggested Solution

The question boils down to this: should we treat VersionInfo as first class object?

I have the impression this isn’t currently the case. The developer can decide between two implementation which does mostly the same. The only difference is, one implementation use strings, the other use a “detour” with an VersionInfo object.

If we would treat VersionInfo as our one and only solution, that would mean we have to move the implementation into the methods. The module level functions would serve as “helper functions”.

Or… maybe we could think about a more radical approach? Are the module level functions really necessary? Should we deprecate them? As we can convert a VersionInfo object into a string through str(versionobject), it seems to me, they are obsolete…

I see the following benefits of this approach:

• Focus on the VersionInfo class, all the magic would happen there. 😉
• Avoids writing two functions which mostly implements the same functionality, but with different types.
• Simplifies testing.
• Focus more on objects than strings (which can’t be controlled).
• Improves the project to be more slim and well-arranged.
• Makes conversion between objects obsolete. Without conversion, it would have a improved effect on performance (maybe only slightly, but…).

If we want to follow this path, we would need:

• Use the warning module to issue a deprecation warning in affected module functions.
• Document the change for our upcoming major release. 😉
• Release 2.9.2 of semver to implement the warnings
• Make the whole removal in release 3 only.

@gsakkis, @scls19fr Does that make sense to you? Do I miss an important point? I would really like to hear your view on this. ❤️

[gsakkis]

@tomschr I fully agree on deprecating and eventually removing the module level functions 👍

[ppkt]

@tomschr I’ve mixed feelings about this - while I agree with your points (especially about duplicated code) - I think we should allow using semver in both ways because a lot of software is using module level functions currently. I checked some popular tools which are using semver: https://libraries.io/pypi/semver/usage:

• mozilla/DeepSpeech
• getredash/redash
• StackStorm/st2

Enforcing OOP it in next major version is completely fine, but maybe it’ll be better to put some extra effort and maintain support for current “users” of module level functions? 😃