Raise exception when push fails

[Sjord]

Closes #621

[Byron]

Thanks a lot for the contribution.

From a usability point of view this is a big step forward. From a stability point of view, it's clearly a breaking change which would require a major release.

Thus far GitPython has no way of collecting this into a major release, nor is there a roadmap to when it should be happening.
Personally I am happy to relentlessly publish major releases, each just containing a small change so it's less work per release. However, it also causes some churn downstream as one has to upgrade more often just to keep receiving patches/fixes.

Opinions on how to handle this are definitely welcome.

[Sjord]

@davidism @mariocj89, you seem to have experience with publishing Python packages with breaking changes. Any recommendations? Should multiple breaking changes be collected in a single major release, or is it OK to create a major release for every change? Should you have release candidates or alpha versions? Should you still maintain the previous branch also?

[mariocj89]

IMHO breaking changes are indeed painful for both the consumer and the publisher.

Should multiple breaking changes be collected in a single major release, or is it OK to create a major release for every change?

It's all a tradeoff! IMHO unless they are too painful to migrate I'd prefer a single breaking release both as a publisher and a consumer. As a consumer I know I only need to worry about a single version to upgrade and as a publisher, I'd have only two branches to worry about supporting. Having multiple major versions with the different breaking changes can add value if you think users will benefit by updating the codebase to the last version "chunk by chunk", which might be useful if the migration is too big to be performed in a single step.
IMHO, In cases like this one, users can already prepare the code base for the new version (adding an except) even if they are using the old one, so I'd go with a single release (assuming other changes are likewise, I'm no expert in GitPython).

Should you have release candidates or alpha versions?

I'd suggest doing that if possible. See how tox or Cython has already a bunch of pre-releases for its next major change. That helps users test early. I'd suggest sharing the fact that there will be pre-releases via twitter, mailing lists, etc to get people to test early.

Should you still maintain the previous branch also?

I'd do so, but for important bugfixes only, and for a limited time, as there will be users that will not have the immediate time to migrate to the new version if changes are needed. If you feel the migration is small enough, pre-releases might be good enough.

To provide some context, for dateutil we are actually going to do something similar, there is gonna be a change that even internal it will probably break some consumers that we are already aware of. We plan to do pre-releases and maintain for a while the old version in a branch.

At the end, I'd just do whatever @Byron feels more comfortable maintaining :).

[Byron]

Thanks everyone for sharing. I might add that the way forward should not add more time or complexity either. Right now I spend between 2-4 hours per month on the project. Adding complexity, like maintaining multiple branches or having pre-releases, will definitely cause some harm as I will definitely mess that up.

Thus any major release would cut off all support for previous major releases, so the question really is how long support for a major version should last at least.

GitPython 3 has been supported for quite some time now and it would be fair to switch to a new major version, but ideally it will be clear how long that should last and based on that answer, it might become obvious how long one would want to collect breaking changes to make it worth it.

If any sort of collection of breaking changes should happen, the creators of PRs would have to rebase them from time to time and resolve all conflicts until the release date has come. When thinking about the likelihood of those being very breaking, it's very discouraging to even think about shipping breaking changes we know of, given that previously it was easy to ship breaking changes unintentionally even.

Maybe that's the answer then? GitPython is in no state to make major releases right now as it has trouble to maintain stability between patch releases. Hence it might be best to close this PR and discourage further PRs with breaking changes even if it would fix long standing bugs, but bugs that people worked around by now.

Of course, if there would be a maintainer for the new major release, an improved and objectively better version of GitPython could still exist, either as a fork or as a branch within this repository (but one that I don't manage, but cut releases from from time to time).

[Sjord]

Hence it might be best to close this PR and discourage further PRs with breaking changes even if it would fix long standing bugs, but bugs that people worked around by now.

I agree. Let's close this PR without merging. I'll see if I can find a non-breaking compromise for #621. And perhaps we should label the issue or the PR as "best-solved-through-breaking-change" or something like that, so that the issue is reconsidered when a major release is done in the future.

[Byron]

Thanks a lot, @Sjord , that solves the matter for now. A label has been added as well, thanks for sharing this idea.

Another solution wasn't considered here even though it definitely is an option: consider this a fix and issue only a patch release for it, independently of the breakage it may cause. This has been done by pytest recently, breaking the CI here out of the blue: b17bc98.

If there are voices for this, please let me know and maybe this PR can be merged after all.