Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
iamjpotts opened this issue Dec 6, 2022 · 7 comments
Open

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

iamjpotts opened this issue Dec 6, 2022 · 7 comments

Comments

@iamjpotts
Copy link
Contributor

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
Copy link
Owner

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
Copy link
Contributor Author

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
Copy link
Owner

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
Copy link
Contributor Author

@ferristseng are you open to additional maintainers?

@ferristseng
Copy link
Owner

@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
Copy link
Contributor Author

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants