Deprecate min_ver/max_ver and use builtin max()/min() functions

Situation

~The min_ver and max_ver functions have currently this signature:~

def max_ver(ver1, ver2):
    # ...
def min_ver(ver1, ver2):
    # ...

~In other words, these functions allow to compare exactly two versions. However, there may be situations, where you have a list of versions. This use case could not be done with the current implementation and needs a cumbersome for-loop.~

As we have comparison operators, there is no need for this functions anymore. Of course, this works only for VersionInfo types, not strings. If someone still wants to compare strings, we could document a replacement.

Action Items:

• add deprecation warning for both functions
• document replacement; maybe something like: max(map(semver.VersionInfo.parse, ['1.1.0', '1.2.0', '2.1.0', '0.5.10', '0.4.99']))

---

Old issue:

Suggested Solution

To allow to compare more than two versions, it would be useful to change the above signature like this:

def max_ver(ver1, ver2, *others):
    # ...
def min_ver(ver1, ver2, *others):
    # ...

This would resemble the builtin functions min and max. The above functions could be used like this:

from semver import max_ver

m = max_ver("3.0.0", "2.0.0", "1.0.0", "4.0.0")
print(m)
# => "1.0.0"

Benefits:

• No incompatible changes to API; it’s still possible to use two arguments
• Only minimal changes in the implementation

Alternative Solution

The proposed solution may has some drawbacks:

• it doesn’t allow to pass an iterable (like the builtin functions min and max).
• could hit a performance bottleneck

If you don’t like the proposed solution, we could:

• leave the current implementation of min_ver and max_ver untouched, or,
• allow iterables in min_ver and max_ver (would introduce incompatible API changes),
• introduce additional functions with the suffix _iter which allows to optimize for iterables. The signature could be:

def max_ver_iter(iterable, *, default=None, key=None):
    """Returns the biggest version from an iterable

   :param iterable: an iterable with version strings
   :param default: specifies an object to return if the provided iterable is empty.
   :param key: specifies a one-argument ordering function like that used for list.sort()
   :raises: ValueError (If the iterable is empty and default is not provided)
    """

Questions

• Does it make sense?
• Should we raise something if the *others tuple contains an invalid version?
• Should we ignore invalid versions? Or provide a flag (something like raise_if_invalid) which can be set?
• Anything else?

[tlaferriere]

I’m a bit concerned about adding functionality to an already deprecated function.

Actually the PR (#264 ) to deprecate these functions hasn’t been merged yet, so these functions aren’t deprecated yet 😉.

As such, the current state of these functions makes them not very useful. Improving could have potential to make them more useful, but if we want to stick to the bare essentials and keep the fluff at a minimum, then maybe the best way to go is to deprecate these functions and make the documentation super clear about how you can use the VersionInfo thanks to it’s magic functions.

If I am feeling the vibe of this project right, I think we want to keep it simple, yet powerful. As such, these are the only two public module functions left that have not been deprecated. I think this might be a sign that we should focus more on having a powerful class that is well documented than having a bunch of utility functions that are probably little used shortcuts for use cases that we can fulfill simply by knowing what VersionInfo is really capable of 💪.

What do you think? Would that be a meaningful approach?

Definitely 😃

[tomschr]

Ahh, thanks for the hint, Thomas! 👍 Even better! I haven’t looked at this issue for some time.

You are right, with the help of the __lt__ and __gt__ operators, it makes comparisons easier. I guess, there is no need for the max_ver and min_ver functions anymore.