Ideas for a new DEP on long-term Django API compatibility
Hello everyone, I'm planning on writing a PEP on long-term API stability for Django. Most of the rationale behind this kind of commitment is described here : https://www.freecodecamp.org/news/api-stability-is-cheap-and-easy/ The idea is that the django ecosystem has suffered a lot, over the past decade, from the numerous breakages happening at each (minor) release. I could write pages just about what "outsiders" like me endured regarding neverending URL patterns changes. Lots of pluggable apps, and their own plugins and bridges, have become incompatible with each other due to sticking to different django versions, or to lack of Tox-like cross-version testing. Some undocumented breaking changes (like classes replaced by other ones but missing functionality, or laziness introduced without autoloading measures for backwards compatibility (RequestContext?)) also hindered misc projects, as seen in their bugtrackers. With *less* work than currently, except small changes in procedures, we can revive the majority of existing packages (except python2vs3 troubles), currently maintained or not, and make upgrades much smoother, which will also improve the overall security of django-backed sites (since users won't fear upgrades anymore). We can thus reach the same regard for compatibility as most industrial-size ecosystems, without sacrificing the cleanness of the codebase, nor its maintainability. For this, imho the best way is just have to include in Django official support for a companion library like https://github.com/pakal/django-compat-patcher , with which I've had immense success There are several ways of doing this, and for this more thoughts are necessary: - putting compatibility sets in the repository, as a django.compt submodule for example? - putting them in an external repository, but strongly advising them in tutorials and otehr docs, like a prime "official project" of django? There are probably aspects of the issue that I'm missing, as I'm not into django "core" development. So your feedbacks are more than welcome! Thanks, regards, Pakal -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1d2f1399-3310-4b36-ae74-9581a0695002%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery
This society also has linters and such, so that DB migrations are safer regarding deployment rollouts - https://medium.com/3yourmind/keeping-django-database-migrations-backward-compatible-727820260dbb On Saturday, June 29, 2019 at 10:36:11 AM UTC+2, Matthieu Rudelle wrote: > > Nice find, It's an interesting way to solve it. We might give it a try. > > On Thursday, June 27, 2019 at 11:12:16 PM UTC+2, Pkl wrote: >> >> Just for reference, here is a package I crossed recently and which has an >> approach for that : https://github.com/3YOURMIND/django-deprecate-fields >> >> On Monday, June 24, 2019 at 3:15:04 PM UTC+2, Matthieu Rudelle wrote: >>> >>> Hi there, >>> >>> I can't find any previous ticket proposing a solution to this problem so >>> here are my findings: >>> >>> **Use case**: >>> When using continuous delivery several versions of the code can be >>> running in parallel on se same DB. Say for instance that release 2.42 is in >>> production, 2.43 is about to be rolled out and in this release one field >>> (say ''MyModel.my_unused_field'') is not used anymore and was removed. >>> Before rolling out 2.43 the DB is migrated and column ''my_unused_field'' >>> of ''MyModel'' is removed. This makes 2.42 crash saying that one column is >>> not found even though 2.42 does not use the field anywhere in the code. >>> >>> **Temporary solution**: >>> Do not makemigrations until de 2.44 release, but it does not scale well >>> with many contributors and CI tools (doing their awesome job of making sure >>> migrations and models are in sync) will complain. >>> >>> **Proposed solution**: >>> Have a ''disabled'' param on Field. When activated this field is not >>> fetched from the DB but replaced by a hardcoded value. >>> In our use case, ''disabled'' is added at the 2.42 release, then when >>> 2.43 rolls out and migrates the DB no error is thrown. >>> >>> **Refs**: >>> - django-users discussion: >>> https://groups.google.com/forum/#!topic/django-users/HY_6rZZ0Kk8 >>> - the same problem discussed in this article, but with a slightly >>> different solution: >>> https://pankrat.github.io/2015/django-migrations-without-downtimes/#django-wishlist >>> >>> (third item in the wishlist) >>> - Previous django-developpers discussion: >>> https://groups.google.com/d/msg/django-developers/5ofrxeLT95E/XhppgA_KAQAJ >>> >>> What do you guys think? >>> >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/012ce55e-a01d-49dc-bb95-993987725a5d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery
Nice find, It's an interesting way to solve it. We might give it a try. On Thursday, June 27, 2019 at 11:12:16 PM UTC+2, Pkl wrote: > > Just for reference, here is a package I crossed recently and which has an > approach for that : https://github.com/3YOURMIND/django-deprecate-fields > > On Monday, June 24, 2019 at 3:15:04 PM UTC+2, Matthieu Rudelle wrote: >> >> Hi there, >> >> I can't find any previous ticket proposing a solution to this problem so >> here are my findings: >> >> **Use case**: >> When using continuous delivery several versions of the code can be >> running in parallel on se same DB. Say for instance that release 2.42 is in >> production, 2.43 is about to be rolled out and in this release one field >> (say ''MyModel.my_unused_field'') is not used anymore and was removed. >> Before rolling out 2.43 the DB is migrated and column ''my_unused_field'' >> of ''MyModel'' is removed. This makes 2.42 crash saying that one column is >> not found even though 2.42 does not use the field anywhere in the code. >> >> **Temporary solution**: >> Do not makemigrations until de 2.44 release, but it does not scale well >> with many contributors and CI tools (doing their awesome job of making sure >> migrations and models are in sync) will complain. >> >> **Proposed solution**: >> Have a ''disabled'' param on Field. When activated this field is not >> fetched from the DB but replaced by a hardcoded value. >> In our use case, ''disabled'' is added at the 2.42 release, then when >> 2.43 rolls out and migrates the DB no error is thrown. >> >> **Refs**: >> - django-users discussion: >> https://groups.google.com/forum/#!topic/django-users/HY_6rZZ0Kk8 >> - the same problem discussed in this article, but with a slightly >> different solution: >> https://pankrat.github.io/2015/django-migrations-without-downtimes/#django-wishlist >> >> (third item in the wishlist) >> - Previous django-developpers discussion: >> https://groups.google.com/d/msg/django-developers/5ofrxeLT95E/XhppgA_KAQAJ >> >> What do you guys think? >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4ee30e7d-f9e5-48ae-8df7-bf415fd34c71%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
