search

ipfs-shipyard / py-ipfs-http-client

A python client library for the IPFS API
MIT License
687 stars 200 forks source link

V0.8.0 support? #252

Open tanevanwifferen opened 3 years ago

tanevanwifferen commented 3 years ago

Can we just bump the required ipfs daemon version?

ntninja commented 3 years ago

I'm aiming to commit a huge set of changes before releasing 0.8 (again, its been delayed several times already). Please ping me in a week if you haven't heard anything from me before that.

ntninja commented 3 years ago

In general upgrading to a new go-IPFS works something like this (but do this yet):

  1. Update the minimum and maximum version in ipfshttpclient/client/__init__.py (next after 0.4.23 was 0.5.0)
  2. Update .travis.yml with matching go-ipfs versions for testing (both number and sha512 hash)
  3. Update README.md with matching version numbers in the note before the table of contents
  4. Open a PR
  5. Ensure that all checks (except for typing which is broken currently) pass, possibly requires patches and version workarounds to be written

^ Not all that bad, but it does take a bit of time.

dokterbob commented 3 years ago

Hey all, I'd like to strongly suggest to change VersionMismatch from an Exception into a Warning, allowing users to use whatever version they'd like. I would consider the current behaviour 'broken by design' from a user perspective; most IPFS behaviour doesn't change between versions but the current behaviour ensures that it still breaks and that seems unnecessary to me. Ref: #253

Of course having full official 0.8.0 support and other changes are super welcome. It's just IPFS 0.8 has been out for a while now and this is a major pain for users, which will occur again and again.

tanevanwifferen commented 3 years ago

@ntninja any update? I see you've pushed a lot of changes already. we're doing manual backups since the latest ipfs release...

c0llab0rat0r commented 3 years ago

@ntninja,

Also interested in a 0.8.0 release. Thanks.

0kalekale commented 3 years ago

lads when are we getting v0.8.0 support

c0llab0rat0r commented 3 years ago

@ntninja has put a lot of time and effort into this great library.

With the interest and activity on it, I wonder if it needs an additional owner/shepherd.

ntninja commented 3 years ago

Somebody want to become co-maintainer? It appears I'm not as enthusiastic about maintaining this as I was when I took this over 5 years ago…

And 0.8.0 isn't the first release that has been greatly delayed for no strong reason either!

ntninja commented 3 years ago

After reviewing recent code I found minor issue #277 that should be fixed before that becomes part of the API in its current form. That's all that is required before actually releasing.

c0llab0rat0r commented 3 years ago

Somebody want to become co-maintainer? It appears I'm not as enthusiastic about maintaining this as I was when I took this over 5 years ago…

And 0.8.0 isn't the first release that has been greatly delayed for no strong reason either!

I'm game to be a co-maintainer. It would be helpful to get any documentation gaps filled in related to release vetting (e.g. any manual steps taken above and beyond CI to ensure the library is ready to release) and related to the release/publish process.

There was also mention of some external commitments related to versions of Python etc. the library must support. It would be helpful to get more information on that.

ntninja commented 3 years ago

I'm game to be a co-maintainer.

I was hoping you'd say (something like) that!

It would be helpful to get any documentation gaps filled in related to release vetting

There a none, CI is fairly comprehensive as it is.

related to the release/publish process

That is documented in https://github.com/ipfs-shipyard/py-ipfs-http-client/blob/master/docs/releasing.md . Wrote that a couple of years ago, but I kept updating it, so it should be fairly up-to-date.

There was also mention of some external commitments related to versions of Python etc. the library must support. It would be helpful to get more information on that.

I've kinda established some rules on this over time, they currently go something like this:

I have not actually received any specific inquires about any of the above, but given the rather broad scope I don't believe anybody can expect more anyways. At the end of the day, this library is just a HTTP wrapper so I think its reasonable not dictate any overly strict version bounds for consumers. All the experimental stuff is happening within go-IPFS anyways.

I also wanted to extend the scope to js-IPFS at some point, but never have gotten around to that.

You have a PyPI account that I can add?

c0llab0rat0r commented 3 years ago

@ntninja I've created a PyPi account with the same name, c0llab0rat0r.

ntninja commented 3 years ago

@c0llab0rat0r: Added you on PyPI.

c0llab0rat0r commented 3 years ago

@c0llab0rat0r: Added you on PyPI.

Accepted.

ntninja commented 3 years ago

Wanna try doing the 0.8 release?

c0llab0rat0r commented 3 years ago

Wanna try doing the 0.8 release?

See #280

c0llab0rat0r commented 3 years ago

@dokterbob do you have any interest in helping with moderation/admin of this library?

cc @ntninja

dokterbob commented 3 years ago

@c0llab0rat0r Not really, I don't have the time for it, but I am very happy and willing to make a 0.7.1 patch release so we finally can get this d#&$# thing to run! I've been waiting many months now just to get my package out.

dokterbob commented 3 years ago

That is to say, I might be willing to support release engineering on a one-off basis. In addition, I'd be willing to create a RELENG.md document with clear release instructions.

c0llab0rat0r commented 3 years ago

Version 0.8.0a1 has been published to PyPi. Version 0.8.0a2 will include some documentation fixes but no functional changes.

Luflosi commented 3 years ago

Can you please also tag the releases for GitHub?