Moving REST framework forward #9270
Replies: 8 comments 14 replies
-
|
I think the DSF option is the best choice, considering the importance of the package. Even if they haven't reached out yet, it may be worth taking a shot 🥛 That being said, what is the biggest need for maintenance / future plans right now? Are there any items that need immediate help from people reading this discussion? |
Beta Was this translation helpful? Give feedback.
-
At a minimum we need someone to determine if there any release blockers for 3.15, which probably comes down to are there any outstanding PRs required in order to fully support Django 5.0? Once we've answered that then we can roll a release. |
Beta Was this translation helpful? Give feedback.
-
|
Got it. I think the discussion on #9210 is a good starting point and I'll check there if there is anything I can help with. |
Beta Was this translation helpful? Give feedback.
-
|
@tomchristie I merged this recently #9233 |
Beta Was this translation helpful? Give feedback.
-
|
The lack of traction over the past 5 months (since 5.0 beta's release) has been very frustrating. I've been waiting since the beginning of the year for a release so I can upgrade my production systems to Django 5, but DRF is currently the only project holding me back from doing so. I assume there are many orgs in the same position that also are struggling with this right now and have likely made the (dangerous) decision to build their own forks and pray for the best. I would be nice to have some clear list of outstanding tasks remaining for a release - there are many people out there who have modified the guts of DRF in the past (including myself) who would be willing to participate if there was some direction from the project's maintainers on what is taking so long and what it would take to get a 3.15 release out the door. It's not even like moving to alternatives is possible either if you're currently the sole maintainer of a project that has hundreds of endpoints. The rework required for that would be massive. FWIW (if anything) I really like jazzband's projects and they seem very open to changes. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to contribute in keeping this project live and working. The lack of any new feature or release to keep up with the development of Django in the last 18 months was a bit frustrating. It would be very good if this project moves under DSF, but I feel that currently it is not on roadmap since "you may implement a Django REST app also without DRF". Probabily the best would be to build a new team of developers/maintainers to keep everything up&running. |
Beta Was this translation helpful? Give feedback.
-
|
Personally, I think DSF is the best option because of its size, number of contributors, and reliability. The proposal to include DRF in django's contrib package has been a popular discussion. However, I think it would be very expensive for django to adopt it, but I think it's worth trying. Do you have a to-do list for DSF adoption? and if so, I'd love to help out a little bit. I think the jazzband is a good organization and team, but as far as I know they do maintenance almost unpaid. Considering the size and impact of this project, I think we need a rigorous maintainer who is more passionate about the project... In my opinion, the most realistic option is still to keep the project in encode... This is because I believe that the most important thing to maintain an open source project is, ironically, money. |
Beta Was this translation helpful? Give feedback.
-
|
I will go with Remain under encode.io - The project remains under encode.io, with new members stepping into a leadership role. As DSF do not have any dedicated resource for it. and I don't think Jazzband is reasonable for a project like this. I started maintaining this back in November 2022. until very recently I got busy with my relocation but as I'm settling down, I think I can continue to contribute. I think If we want we can cut a release in next 2 weeks for sure. @tomchristie |
Beta Was this translation helpful? Give feedback.
-
|
Okay, thanks everyone... consensus seems to be that we're probably in the right place at the moment, tho we need to get things back on track.
|
Beta Was this translation helpful? Give feedback.
-
|
It should be maintained, yes. Intent should be minimal noise on here, keep pace with changes in Django and squish any security issues. It doesn't need any ongoing featurification. |
Beta Was this translation helpful? Give feedback.
-
|
The issue list since the 3.15 release is a good example of the negative trade-offs that changes to the project introduce at this point in it's lifespan... 
...We'll be able to resolve those and get a new point release out, but it highlights where our priorities for the project should be. Our policy (in my view) should be a very clear...
...The project is mature, with plenty of scope for third party packages and adaptation. Further changes at this point are just creating risk, churn, and unnecessary busy-work. |
Beta Was this translation helpful? Give feedback.
-
|
This part of the documentation seems to hint at adding some features to the framework, are there still plans to add Websocket & JWT & CORs support? (https://fund.django-rest-framework.org/topics/funding/) Or would it be better to improve the documentation? (I apologize if this is a sensitive area, I just wanted to know what your thoughts are on this at this point). |
Beta Was this translation helpful? Give feedback.
-
|
There's no off-limit conversations here... yep those aspects of the documentation are long out of date. (The funding did help WebSockets support in Django, to the extent that I think what we actually want at this point in time is redirecting our funding pages towards https://github.com/sponsors/encode and figuring out how we can be dealing with sponsorships and our available funds across the whole range of |
Beta Was this translation helpful? Give feedback.
-
|
Hi @tomchristie, I agree with the scope you laid out above for maintaining DRF, and am interested in stepping up as a maintainer. |
Beta Was this translation helpful? Give feedback.
-
|
👋 DSF board member here. I’ll add this to the agenda of internal DSF discussions. |
Beta Was this translation helpful? Give feedback.
-
|
We discussed this in yesterday’s DSF board meeting and confirmed what others have said above, which is that we care about the success of DRF but the DSF doesn’t currently have capacity to look after more packages. We have DEP 7: Official Django Projects as a policy when adopting projects under the Django org, however this still requires forming a maintainer team and renewing it over time. Which is the hardest part of maintenance. So doesn’t feel like it would help too much here (happy to be told otherwise). And – people like Django Fellows who are paid to do maintenance and community support – are paid to do so for Django itself. They can work on helping with other packages as they deem appropriate, but that’s at their discretion. Everything else is volunteer-based. Back to what the DSF can do – collaborative package maintenance over time is a real challenge for open source communities like ours. And DRF is in use in about half the projects out there, so we definitely want to help how we can. In the short term I’ll get in touch with other people at the DSF and ask them for thoughts. Lots will have experienced package maintenance challenges for Django itself, and with Jazzband, and elsewhere. We have a DSF working groups mechanism to make Django community things happen with formal support (a budget, infrastructure, comms w/ other Django initiatives, etc). Perhaps a package maintainers working group could be a good way to support the new DRF maintainers in the short term, and also help with open source sustainability considerations in the wider ecosystem? In the very, very short term – our Django Discord server has a #packages channel, which is a good place if you want to ask maintainers for their wisdom. And not Django related but GitHub as a great Maintainer Community which I’d recommend as a safe place to ask tough open source community questions. |
Beta Was this translation helpful? Give feedback.
-
Probably another 10%-20% of projects are doing APIs without DRF. It sounds like Django REST Framework should be built into Django instead of being an optional add-on. FastAPI and other modern web frameworks are a recognition that APIs are vital (not optional) for building modern web applications. |
Beta Was this translation helpful? Give feedback.
-
|
Valid point. Personally I’d recommend considering this separately from maintenance of DRF. See recent roadmap-level discussions on the Django Forum, in particular Built-In API Framework. There was interest but no one volunteering to make a more fleshed-out proposal. I’d recommend starting a discussion on the Django forum to take this further. |
Beta Was this translation helpful? Give feedback.
-
|
This came up again in discussions at DjangoCon Europe. There's no appetite to merge DRF into core, but plenty of people expressed the desire for DRF to not just continue to be maintained (in stasis) but be allowed to evolve again. (e.g. cc-ing @tfranzel, who maintains drf-spectacular was quite passionate in that camp) As @thibaudcolas says, I think the DSF taking it on is only feasible if we can answer the maintenance question. That would need to be a paid role, as for all the discussions I had, nobody said that they were prepared to take on DRF on a volunteer basis. Everyone wants DRF maintained as long as they're not the one doing it, it seems. 🙂 That's totally understandable, but it clearly highlights how any solution here needs to look. I personally have drifted too far from DRF and am not able to maintain it even on a paid basis. |
Beta Was this translation helpful? Give feedback.
-
|
The only thing that needs to be happening in my perspective is to adopt the Djangorelease roadmap. Under which flag this happens is less important since the same people will do the heavy lifting. According to the roadmap the next release would be Django 5.1 plannend for august. Since shared responsibility is no responsibility I think community should appoint a release manager. |
Beta Was this translation helpful? Give feedback.
-
|
Having a release process in line with Django's is certainly a good idea. Perhaps someone would be motivated in drafting a change to the project management docs which are somewhat out of date.
The lifting here should mostly consist of... improving the docs, making sure we've got a nice safe release process, handling security issues, dealing with any updates strictly required by newer Django versions, and helping say "no" to pull requests and issues.
I'm unsure how we should handle that. Interested individuals could self-nominate in this thread as a starting point, perhaps? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey all,
REST framework could clearly do with new leadership at the moment.
The latest release was 18 months ago and since then I've hardly had any spare bandwidth to dedicate to the project.
(My open source work is currently almost all directed at
httpx, which feels by far the best use of my time.)There are a handful of options that seem reasonable to me...
The project is in good shape & widely used, and there's plenty of businesses that I'd assume have a stake in helping out here.
We also have ongoing sponsorships at the moment which we've options with, either allowing us to fund new contributors or continuing to enable other work under the encode banner.
I'm interested in feedback from potential contributors around these options in order to help us start moving the project forward again?...
Beta Was this translation helpful? Give feedback.
All reactions