Giters

square / retrofit

A type-safe HTTP client for Android and the JVM

Home Page:https://square.github.io/retrofit/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Summary: New maintenance release | projects state | vulnerabilities in dependencies (CVE's)

Lonzak opened this issue · comments

commented

First I would like to express my gratitude to all of the project maintainers who kept and keep working on this project. It is heavily used so your work is appreciated.

Originally I just came here to confirm that this project is dead but then surprisingly I saw that this is not the case. After a bit of digging I found lots of requests / pleas for an update for different reasons. Over a year ago some has been summarized here and in countless other tickets. I will try to summarize and categorize some of them here.
It would be appreciated if this ticket would not be closed too quickly - then others don't need to open new tickets for their update request. This will thus hopefully save you some time which could be spent on more important things...

Reason for not updating (yet):
Some answers which were given:

"We will release when we release. This library has not been a priority recently, but is otherwise stable and working.
In general, both in the past over the history of the project and in the future, we will never do a release to solely address an issue bump for a transitive dependency. Those come along for the ride with new features and bug fixes within this library."

and

"Unfortunately the project isn't quite in a state that I'm comfortable releasing so it requires some time to get back to a releasable state."

and

"I'm on paternity leave. Perhaps when I get back."

Many maintainers contribute and maintain in their (private) spare time. This can not be stressed enough and deserves respect.

But I also see that three years of "bug fixes and maintenance" would and should be quite a reason to make a maintenance release.
Due to supply-chain attacks, transitive dependencies become more and more important and critical. Those third party dependencies belong to a project because they are distributed along with it. (Just look at all the projects which were updated due to the bug in log4j...)

Sure there are mechanisms to manually or automatically exclude them but it means always extra effort to do so. Our project for instance has way over 100 dependencies and each unmaintained lib means additional work (and discussion with the security guys etc.). And this is only the security side. There are bugs listed below which need manual intervention to circumvent those.
In the end we are all just trying to say that the community would appreciate a maintenance release from time to time :-) (where time < 3 years)

Now a list of tickets follows which (for different reasons) all have the same topic:

Vulnerabilities in (transitive) dependencies

Bugs (excerpt):

General Project state questions:

commented

Thank you for this write-up. I'd like to add another point in response to:

"Unfortunately the project isn't quite in a state that I'm comfortable releasing so it requires some time to get back to a releasable state."

Anyone who has required Retrofit changes from the past 3 years has probably been relying on version 2.10.0-SNAPSHOT. This is the case in my own projects.

No matter the current state of the project, surely it's better to provide stability through an official release than to have consumers increasingly rely on volatile Snapshot versions?

Thanks again to the maintainers for all their hard work on this.