Discussion: PyPI name transfer

[madsmtm]

Hi @c4urself, and other maintainers!

Just perusing the PEPs today, and thought about this project while reading PEP-0541 (especially the section on continued maintenance of an abandoned project).

And hey, it's been years since @peritus updated the original project, and I'm assuming they've been completely unreachable ever since, have you considered attempting to get the PyPI maintainers to transfer the project to you?

After all, the original PyPI package still has at least 10 times as many downloads monthly (and at least 2 times when excluding Python 2 users) (according to pypistats.org), so getting the PyPI project would also mean that the people currently using it could receive improvements/patches.

Just some food for thought, and in general, thanks for maintaining the fork! 👍

[peritus]

I'm super happy to transfer the name to an active maintainer, ideally a group of people (@jazzband ?) that have a long-term interest in supporting this. Also happy to help with the transition.

[c4urself]

Right now we've got three collaborators on this GitHub project: myself, @ekohl and @anthrotype we can add some more depending on interest/motivation, for example: @florisla has been helping out quite a bit, thanks! So far it's been working pretty well (AFAICT) the way it is, but I'm open to discussion. What's the process look like for transferring/combining the projects again?

[tjanez]

Hi!

I'm new to this project but I would like to share some of my thoughts on the subject.

What's the process look like for transferring/combining the projects again?

For PyPI, @peritus would need to make your PyPI user an owner of the bumpversion project. Probably it doesn't make sense to release all interim versions that happened on bump2version project to the bumpversion project. Rather, you would probably want to release version 0.6.0 or something to signify the start of a new era.

For GitHub, it probably makes more sense to continue on the original repository, i.e. https://github.com/peritus/bumpversion, since it has more stars, issues and pull requests.
There are many options on how @peritus could give you (co)ownership:

• he could give you co-ownership of the repo (URL stays the same), or
• transfer the repo, either to you directly (so it would become https://github.com/c4urself/bumpversion/) or to an organization that would be created for it.

The git part should be fairly straightforward. You would just fast forward the changes here to the original project's master branch and probably also copy the tags

Afterwards, you would probably want to transfer any open issues & pull requests in this repo to the original repo. There are not so many at the moment (24 open issues, 7 open pull requests), so this wouldn't be a big issue.
And finally, update the README in this repo to point people to the new home and archive this repo.

[vEpiphyte]

re: New release - I would suggest that any updates to the bumpversion package distributed through pypi have a new minor point release at a minimum as @tjanez suggests, so users could version lock themselves lower if needed.

The annotated tag change here #1 can be problematic for users if their CI/CD tools are not expecting annotated tags to suddenly appear. For example, CircleCI workflows did not support annotated tags historically [1]. Making the annotated tag feature capable of being disabled via a setting in .bumpversion.cfg could allow users to experiment with newer versions and ensure that existing workflows function properly prior to going all in on that change.

[1] Their documentation for workflows now notes support for annotated tags.

[ekohl]

As one of the co-maintainers I'd be happy to centralize all our efforts in the original package. The only reason we chose an alternative name is peritus/bumpversion#169 (comment). The Fedora bumpversion package actually uses bump2version and I'm sure many others have switched as well.

@tjanez laid out a good part of the steps.

@vEpiphyte tools unable to handle annotated tags sounds weird to me since unannotated tags usually need special handling rather than annotated tags. There is already an option --tag-message with an equivalent setting. It has a default value but an empty string disables it so I wouldn't worry about broken tools.

[peritus]

I’ve just added @c4urself as a collaborator on https://github.com/peritus/bumpversion and hope I can make him an admin once the invitation is accepted, so he can then do all the things needed with regards to pushing to master, accepting PRs, settings, inviting further collaborators he trusts.

Now I need to figure out how to do something similar on PyPI ... 🤔

[tjanez]

Now I need to figure out how to do something similar on PyPI ... thinking

Browse to https://pypi.org/manage/project/bumpversion/collaboration/ and add c4urself as Owner.

[peritus]

Now I need to figure out how to do something similar on PyPI ... thinking

Browse to https://pypi.org/manage/project/bumpversion/collaboration/ and add c4urself as Owner.

Done. ✅

[madsmtm]

Regarding release, you should consider continued release to both PyPI projects (so that users of the soon-to-be old bump2version aren't left out) - Other than that, I agree with @tjanez

[ekohl]

I see this project is no longer considered a fork of the original. Is that intentional or a Github oddness?

[florisla]

@c4urself Can you confirm you have control of bumpversion on PyPI?

I'd recommend to make a GitHub organization and transfer this repository to there. If maintainership would change in the future, it's easier to change that through an organization.

This fork's issue queue is shorter than the original's and I'd rather have a clean queue and a correct release history than a lot of stars.

[peritus]

FYI: I just added a small section to the top of the README describing the current status of the project, directing people using bumpversion to the fork as well as to this very discussion peritus/bumpversion@cc3c8cf.

[florisla]

@c4urself You said "Right now we've got three collaborators on this GitHub project (...) So far it's been working pretty well (AFAICT) the way it is"

I think we should improve the cycle time a bit for both issues and merge requests.

Some merge requests go months without even a reply, which is not motivating for the contributors.

Let's start with resolving this issue to start with ;-)

I can help out maintaining issues; can you give me permissions to set labels on them?

[ekohl]

Now we're getting slightly off topic, but I'd be happy to give @florisla full collaborator status given his past contributions and involvement.

[c4urself]

I have access to the PyPI bumpversion project as well as collaborator status on the original repo on GH (thanks @peritus);

We have two things to contend with:

1. a name change to the package (pip install)
2. a name change to the GH repo

For 1:
I think the right step to take is to deprecate the old project by pushing an empty package to the original PyPI's project that only contains packaging information and depends on bump2version. That is the PyPI recommended way described here: https://www.python.org/dev/peps/pep-0423/#improved-handling-of-renamed-projects-on-pypi. -- it will also allow a seamless upgrade to folks wanting to upgrade the original bumpversion as well as allowing (new) users of bump2version to carry on using that without changing their requirements.txt. I propose releasing a 0.6.0 on that original project that references the latest bump2version, which would be that project's final release. This would allow folks to keep with the old version if so desired by keeping on the 0.5.x minor version.

For 2:
Seeing as this transition has caused some churn within the community (see: https://github.com/Homebrew/homebrew-core/pull/47379/files as an example) maybe we should not change the GH repo (to an org) again and just keep things this way for a bit until we've figured out 1. At that point we could move things a (hopefully) final time to an organization. In addition I agree with @florisla about keeping things (relatively) clean with tickets and discussions here.

If I don't hear disapproval for my suggestion to push an empty project to the original repo, I'll proceed with that in a week or two.

For now, I'm going to follow @florisla's suggestion and get back to ticket triage and moving the project forward.

[andrivet]

Any progress on this? Just to know if I continue my advbumpversion or if there is any chance to merge the different forks.

[etos]

RIP the plaster off please. :)

[danielbraun89]

@c4urself Why bother with name changes and name contentions? Just rebase your repo into github.com/peritus/bumpversion, and upload a new releases into pypi 'bumpversion'

[c4urself]

A "week or two" is apparently a few months instead 🦊. I've just pushed an empty shell dist to the old project: https://pypi.org/project/bumpversion/0.6.0/ which simple adds bump2version as a requirement and installs the latest. (see PR here: peritus/bumpversion#210)

@danielbraun89 -- to answer your question, not doing a rebase because we'd like to keep this project for discussion/tickets etc (see part 2 of answer above)
@etos -- done :)
@andrivet -- I've completed the transfer, would be great if we can merge advbumpversion back as well at some point.

[tjanez]

I would suggest to also update the README since the following is no longer the case:

This is an interim fork of the excellent project that can be found here: https://github.com/peritus/bumpversion
In the future, both projects will re-merge with backwards compatibility as a goal (issue 86).

[luiscoms]

It could be created an organization, it would be easy to manage maintainers.

[MartinThoma]

bumpversion still states:

there's an ongoing discussion about merging the fork back to the original project

Is that really still on the table? I had the impression that bump2version is just the new thing and bumpversion is (and likely will be) inactive.

[c4urself]

@MartinThoma that's correct, we've just been taking things slowly / conservatively...

[florisla]

@c4urself You have less interest in maintaining bump2version, correct?

That would be a good argument to transfer the repo to a GitHub organization.