search

ferristseng / rust-ipfs-api

IPFS HTTP client in Rust
Apache License 2.0
246 stars 68 forks source link

Question - What's the Maintenance / Deprecation Status? #118

Open iamjpotts opened 1 year ago

iamjpotts commented 1 year ago

At the top of the README, there's a deprecation badge, but later on in the readme, only one of the crates ipfs-api is marked deprecated in a table listing all the crates in this repo.

Is only ipfs-api deprecated, or the entire repo?

If the former, should the readme be refactored to have the deprecated items in a separate document?

"Passively maintained" sounds softer than "deprecated" which has a permanent connotation.

ferristseng commented 1 year ago

I'm not really actively developing this project anymore, but am accepting user contributions, hence the "Passively Maintained" status. I haven't had anyone interested in taking over the project, but am open to that.

ipfs-api was the first crate I published the code under, but the build process was complicated because both the Actix and Hyper backends were combined in a single crate. I'm still updating it whenever I deploy the backend crates, but picking one of the backend crates is preferred, and I may stop updating ipfs-api if/when I decide to publish 1.0.

iamjpotts commented 1 year ago

I liked having ipfs-api as a single entrypoint, and switching between implementations using features. It leaves the implementation hidden (mostly) from whatever is using the library, which I think is good.

How do you envision the crate(s) being used by applications without using the ipfs-api crate?

ferristseng commented 1 year ago

I liked having ipfs-api as a single entrypoint, and switching between implementations using features. It leaves the implementation hidden (mostly) from whatever is using the library, which I think is good.

I think the problem with this was having multiple sets of features and not knowing which were compatible with which. Having separate crates for hyper vs actix makes it easier to grok IMO.

How do you envision the crate(s) being used by applications without using the ipfs-api crate?

I think the better way is to pull in ipfs-api-backend-hyper or ipfs-api-backend-actix instead of using the ipfs-api.

iamjpotts commented 1 year ago

@ferristseng are you open to additional maintainers?

ferristseng commented 1 year ago

@ferristseng are you open to additional maintainers?

Yes! Definitely open to it. I've had one in the past. Are you interested in becoming a maintainer?

iamjpotts commented 1 year ago

I could potentially, in a limited capacity - enough to keep incoming PRs active and unblocked. It would be helpful to have others also.

What kind of standards do you have for contributions - what's the current status quo or what do you think is appropriate for this project to both keep it active (not be too restrictive / draconian) and maintain a degree of quality?

ferristseng commented 1 year ago

I could potentially, in a limited capacity - enough to keep incoming PRs active and unblocked. It would be helpful to have others also.

What kind of standards do you have for contributions - what's the current status quo or what do you think is appropriate for this project to both keep it active (not be too restrictive / draconian) and maintain a degree of quality?

Hmm good question, I've been pretty loose, not even really having unit tests for most things. I've mostly been accepting contributions to add support for new IPFS endpoints, while keeping the core stuff pretty much untouched. A maintainer could definitely help shepherd those things along, as I am really following IPFS development anymore.