My opinion (my 2cts)

We will release in the next coming days / weeks a 2.9.x version of python-semver which will support Python 2.7 and 3.x

After this, we will be working on a 3.x version of python-semver which will only support Python 3.x

I won't personally backport python-semver 3.x features to 2.x branch to urge people to leave this venerable Python 2.7 version (in life everything stops one day 😉 )

Releasing is time consuming... releasing 2 versions can be more than 2 times consuming.

I fully agree - I think we should only fix bugs in 2.x branch.

Another question - what about Python 3.4? It's marked as EOL and maybe we should remove support for that version as well in 3.x?

Another question - what about Python 3.4?

I was thinking the same. Maybe we can mark this version also as unsupported in our upcoming 3.x branch?

Agree no Python 3.4 in python-semver 3.x but Python 2.7, 3.4 in python-semver 2.9.x

Ok, great! So to summarize the needed actions:

• Create a 2.9.x release with the subtasks:
  • Add the current document state/idea into the README
  • Mention the plan for the 2.9.x "maintenance" branch
  • Open a maint/2.9.x(?) maintenance release branch (choose a name you like).
    This would be only for interested people, no backporting will happen

This part is covered now in #127

• Create a 3.x release with the subtasks:
  • Remove test target py27
  • If needed, remove/refactor code that was introduced only for Python 2.7
  • If needed, "optimize" code for Python3
  • Focus on Python3 in the documentation
  • Adapt setup.py: remove lines with support for Python 2.7 and 3.4

Anything else?

@scls19fr @ppkt
I'd suggest to make our user base aware of such an "incompatible" change and add a warning notice in our README file. What do you think about this? 😉

.. warning::

   Major version 3.0.0 of semver will remove support for Python 2.7 and 3.4.

   As anything comes to an end, this project will focus on Python 3.x. New
   features and bugfixes will be integrated only into the 3.x.y line of semver.

   The last version of semver which supports Python 2.7 and 3.4 will be
   2.9.x. However, keep in mind, version 2.9.x is frozen: no new
   features nor backports will be integrated.

   We recommend to upgrade your workflow to Python 3.x to gain support,
   bugfixes, and new features.

Furthermore, I would suggest to add this in the upcoming 2.9.0 release.

LGTM

@scls19fr
Thanks for merging it, 👍 but it's only one part of it. I've mentioned other items in my #161 (comment).

Should we transfer the other, unresolved items into a new issue or is it better to reopen this issue?

Ok so let's reopen and adress remaining items.

The comment #161 (comment) that mentions Python 3/semver 3.0.0 is covered in a separate issue #176 now.

@python-semver/reviewers
As far as I can see, from #161 (comment), only the maintenance branch is open:

Open a maint/2.9.x(?) maintenance release branch (choose a name you like).
This would be only for interested people, no backporting will happen

When should we create such a branch? (As Python 2 is now EOL).

Probably we want to create another release before, right?

I'm confused by the statement in the Readme that seems to say 2.10.0 does still support Python 2.7. That's not what I'm seeing. I have a project that uses this package and runs in Py2, and as soon as it started using the 2.10 release, I started getting errors like this which look to me like what you'd get from a Py2 vs. Py3 incompatibility:

TypeError("Expected str or VersionInfo instance, but got <type 'unicode'>"

When I pin the dependency to <2.10, the error goes away.

@eli-darkly Thanks Eli! 👍 Much appreciate your bug report. I've opened #274.

If I'm not mistaken, I assume this is of some if isinstance(other, str) lines which didn't recognize the unicode datatype in Python2.

I've opened a maintenance branch maint/v2 if we need that for the semver v2 line.
I think, all tasks are done so I'm closing this issue for the time being.