fedpkg

#171 Do not check bodhi-client version
Closed: Invalid Opened by cqi.

Closed: Invalid
Reopen Issue

Currently, fedpkg tries to get bodhi-client version and check it in case that version is not supported. This was added for adding compatibility of v1 and v2 at same time.

Line https://pagure.io/fedpkg/blob/master/f/fedpkg/init.py#_240 checks the version and reports error when each time bodhi-client increases major version for a new release. There could be a problem that is once that happens and the command line interface has no change, fedpkg has to be changed as well by changing the minimum unsupported version. It's not good.

To fix that, this issue is a propose for removing that version check. As long as bodhi-client command line is stable enough and has no changes to what fedpkg uses, there is no need to check the version. On the other hand, from fedpkg point of view, we can't know in which future version bodhi-client will change the CLI UX again, so it's impossible for us to choose a proper minimum unsupported major version.

Also, today, Dec 12, 2017, it's Fedora 25 EOL. We don't need to build Fedora 25 packages for future releases and fedpkg will not work with bodhi-client v1. Checking bodh-client version should not be necessary too.

@lsedlar @bowlofeggs What do you think?

I agree about dropping support for version 1. No one should use that (however the Requires on the package should be updated to ensure that).

I would even drop the check for next version. When next Bodhi comes out, if the UI does not change it would work immediately with no required action. If the UI changes, there will obviously need to be some change needed in fedpkg.

With the check we need to update fedpkg even if next bodhi has similar interface to the current one.

Don't forget that EL6 still has bodhi 0.9, and actually can't easily be upgraded to Bodhi 3 (or 2). I'd recommend at least keeping that version check in the EL6 build of fedpkg.

As for the future, I'm hoping to someday break the bodhi client code out from the server code so they can be versioned independently. What happened with Bodhi 3 is that the server got a backwards incompatible change but the client did not. However, if/when I split the client out into its own package, a major version change would indicate a backwards incompatibility in the client. That wouldn't necessarily mean that the way that fedpkg uses it would break, but it would mean that someone should verify it.

Oh right, I completely forgot about EL6. We do need to keep the check then.

Yup, right, I also forgot the EL6 :) I think checking "if current distro is el6?" would be flexible for fedpkg than checking the version.

Metadata Update from @cqi:
- Issue set to the milestone: NEXT
- Issue tagged with: bodhi

Metadata Update from @cqi:
- Issue assigned to cqi

PR: https://pagure.io/fedpkg/pull-request/185
Edited by cqi

As mentioned in PR #185, it is not a good time to make this change now. Just close this issue. If this is worth to do in the future, feel free to reopen and continue to resolve it.

Metadata Update from @cqi:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

Metadata Update from @onosek:
- Issue set to the milestone: None (was: NEXT)
Metadata

bodhi

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.