release 4.0 #168
release 4.0 #168
Conversation
|
Hey @belugame, I would have liked to address #156 first as it really brings a valid point forward, especially regarding security / good practice. I'm not sure I would block the release though, we can still make more backward incompatible change later on anyway. Thanks for taking the time to do this PR 🎉 |
|
Hello friends, (and now sorry for the wall of text.) First I would like to address the #156 discussion and specifically this and this -- I can see where you come from in that yes technically it is more secure and there are usecases for it -- but I still believe that in the real world this should at least not be the default behaivor (at least not yet). My reasoning for saying that is partly what I initially wrote here but secondly and honestly probably the most important one (at least for me) -- users already rely on this library and I dont want to force a entirely new mechanism onto them which might break their apps. This is not right (but I get that it sometimes is unavoidable). Dont break the default and expected behaivor, but we should still facilitate new functionality of course. Another response to this is that one could just "not update the library" -- well thats not a good nor responsible way of treating users of your software because currently there is no concept of backporting security patches to older versions in this project as far as I can tell and no 'deprecation schedule' so to most users it will come as a surprise and be thrown under the bus. Lets not do that. Another problem I have found myself with in in the django world is that projects tend to be abandoned or untrustworthy because they eventually change so much that it breaks the apps in which they are integrated into. Don't get me wrong here, sometimes this is unavoidable and also a natural progression over time for a library. But in the case of #156 discussion it is avoidable in that it should not be the default behaivor. I just dont want this project to end up in that pile of abandoned projects or ones that cannot be trusted in the long run because they keep breaking the apps that uses them because of major API changes. The current drf-knox implementation is secure so much so that a "lesser" secure version is shipped by default by django-rest-framework. I want to serve the longtime users, and not break things while still being relevant in terms of security. I enjoy this project which is why I started contributing to it in the first place, cause I believe the foundation is a good one and I believe in stability and usability. Again, these are just my two cents, I'm happy to finish #158 to be able to release 4.0 @belugame -- if not, then toss it and lets continue discussing #156 until we reach a consensus on how to proceed. I'll be honest and say this is a complex topic and it is hard to get it right so it does indeed postulate proper discussion. Sincerely, |
|
Hey @sphrak, Don't feel bad about being away from the project, we spend our time freely on this kind of project and having higher priorities is completely normal 👍 You raise some valid points regarding deprecation warning and security backports. I would also argue that you are not making your library's user a favor by influencing them in using bad security practice and the change discussed in #156 is all about that, not opening the door to bad practice. One of the reason I like Django so much is that it pushes good practices on the user, by being opinionated, in a good way. Also, I think that if we want to be "trustable", we should hold the release until #156 is settled then. Cheers 🍺 |
|
Take your time :) A major release should not be rushed. Users can still pin the master version of the repo into their requirements.txt as a temporary workaround if they need to. |
release 4.0
No description provided.