Re: 1.9 release planning
I think Collin's proposal can match semver without additional overhead when LTS are the final minor releases of any given major branch. 1.8 LTS 2.0 (Drop features from 1.7) 2.1 (Drop features from 1.8 LTS) 2.2 LTS 3.0 (Drop features from 2.0, 2.1) 3.1 (Drop features from 2.2 LTS) 3.2 LTS That way we can say that features are never removed until the next major release. Features deprecated in a LTS leak onto x.1 releases but that's fine (1 release deprecations are a no-go IMO), we can document it as "deprecations from a major branch will be either loud or gone in the following major branch". -- Loïc > On Jun 13, 2015, at 04:16, Tim Graham wrote: > > I'm still in favor of "Collin's proposal." You'll need to convince me that > keeping deprecations around longer is worth having somewhat meaningful > version numbers, but I'm not sure I really consider dropping deprecation > shims as "incompatible API changes" that justify a major version bump. For > example, if I run on 2.X (whatever is right before the version where features > are dropped) without deprecation warnings, then upgrading to 3.0 isn't any > more difficult than other upgrades. It might be a nice touch to call the > version after the next LTS (2.1 under Collin's proposal) "3.0" since it will > drop Python 2 support, but it's not really important IMO > > On Friday, June 12, 2015 at 8:00:30 PM UTC-4, Ryan Hiebert wrote: > An alternative would be for the LTS to be the second-to-last minor release > before a major version bump. > > I'm also ignoring the transition for the sake of hypotheticals. I'm also > assuming that 2.2 is the last release of the 2.X series. > > 2.1 - 0 mos - (LTS) No features dropped > 2.2 - 8 mos - No features dropped > 3.0 - 16 mos - Drop all features deprecated by 2.1 > 3.1 - 24 mos - (LTS) No features dropped > 3.2 - 32 mos - No features dropped > 4.0 - 40 mos - Drop all features deprecated by 3.1 > 4.1 - 48 mos - (LTS) No features dropped > > It would mean that features deprecated before an LTS cannot be dropped until > two versions after the LTS, but it fits semver pretty well, and doesn't speed > up our deprecation removal. > > I'd argue for a major version dropping _all_ deprecated features. This has > the downside of speeding up our removal process in the last version of a > major release, and it encourages people to stay longer on the release > previous, since they won't have as much opportunity to fix them. It would > also mean that features deprecated in the last minor version of a major > version line would need to skip the pending deprecation warnings. > > If it were acceptable to do that, then I'd argue for the LTS to be the _last_ > in a major version line, rather than the second-to-last. That would probably > be my overall preferred, though I do recognize the previously mentioned > drawbacks. Anything deprecated in an LTS in that case would skip the pending > deprecation warning, and go straight to the deprecation warning. The > deprecation timeline would then look like this: > > 2.2 - 0 mos - (LTS) No features dropped > 3.0 - 8 mos - All deprecations, including the LTS deprecations, are removed > 3.1 - 16 mos - No features dropped > 3.2 - 24 mos - (LTS) No features dropped > 4.0 - 32 mos - All deprecations, including the LTS deprecations, are removed > 4.1 - 40 mos - No features dropped > 4.2 - 48 mos - (LTS) No features dropped > > > I think those are probably the two best LTS support release schedules that > follow semver. > > Ryan > > -- > 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 http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/f887421b-c470-491f-b5f0-a12af397bfe1%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2A833F90-C4AA-449F-BF97-B0514FA4F210%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: 1.9 release planning
I'm happy to give it a try if there's consensus that it might help. On the other hand, this doesn't account for the inevitable backwards incompatible changes that come along. For example, someone in the survey said "Django 1.7 is a hard change for clients and it should have been 2.0 so that they realize what the jump means." Unfortunately, it's impossible to anticipate when features like that might come along and I'm not sure we'd want to delay features so that they don't first appear in an LTS release (at least, this would be a pretty big change in Django development and slow down innovation in my view). On Saturday, June 13, 2015 at 6:25:44 AM UTC-4, Loïc Bistuer wrote: > > I think Collin's proposal can match semver without additional overhead > when LTS are the final minor releases of any given major branch. > > 1.8 LTS > 2.0 (Drop features from 1.7) > 2.1 (Drop features from 1.8 LTS) > 2.2 LTS > 3.0 (Drop features from 2.0, 2.1) > 3.1 (Drop features from 2.2 LTS) > 3.2 LTS > > That way we can say that features are never removed until the next major > release. > > Features deprecated in a LTS leak onto x.1 releases but that's fine (1 > release deprecations are a no-go IMO), we can document it as "deprecations > from a major branch will be either loud or gone in the following major > branch". > > -- > Loïc > > > On Jun 13, 2015, at 04:16, Tim Graham > > wrote: > > > > I'm still in favor of "Collin's proposal." You'll need to convince me > that keeping deprecations around longer is worth having somewhat meaningful > version numbers, but I'm not sure I really consider dropping deprecation > shims as "incompatible API changes" that justify a major version bump. For > example, if I run on 2.X (whatever is right before the version where > features are dropped) without deprecation warnings, then upgrading to 3.0 > isn't any more difficult than other upgrades. It might be a nice touch to > call the version after the next LTS (2.1 under Collin's proposal) "3.0" > since it will drop Python 2 support, but it's not really important IMO > > > > On Friday, June 12, 2015 at 8:00:30 PM UTC-4, Ryan Hiebert wrote: > > An alternative would be for the LTS to be the second-to-last minor > release before a major version bump. > > > > I'm also ignoring the transition for the sake of hypotheticals. I'm also > assuming that 2.2 is the last release of the 2.X series. > > > > 2.1 - 0 mos - (LTS) No features dropped > > 2.2 - 8 mos - No features dropped > > 3.0 - 16 mos - Drop all features deprecated by 2.1 > > 3.1 - 24 mos - (LTS) No features dropped > > 3.2 - 32 mos - No features dropped > > 4.0 - 40 mos - Drop all features deprecated by 3.1 > > 4.1 - 48 mos - (LTS) No features dropped > > > > It would mean that features deprecated before an LTS cannot be dropped > until two versions after the LTS, but it fits semver pretty well, and > doesn't speed up our deprecation removal. > > > > I'd argue for a major version dropping _all_ deprecated features. This > has the downside of speeding up our removal process in the last version of > a major release, and it encourages people to stay longer on the release > previous, since they won't have as much opportunity to fix them. It would > also mean that features deprecated in the last minor version of a major > version line would need to skip the pending deprecation warnings. > > > > If it were acceptable to do that, then I'd argue for the LTS to be the > _last_ in a major version line, rather than the second-to-last. That would > probably be my overall preferred, though I do recognize the previously > mentioned drawbacks. Anything deprecated in an LTS in that case would skip > the pending deprecation warning, and go straight to the deprecation > warning. The deprecation timeline would then look like this: > > > > 2.2 - 0 mos - (LTS) No features dropped > > 3.0 - 8 mos - All deprecations, including the LTS deprecations, are > removed > > 3.1 - 16 mos - No features dropped > > 3.2 - 24 mos - (LTS) No features dropped > > 4.0 - 32 mos - All deprecations, including the LTS deprecations, are > removed > > 4.1 - 40 mos - No features dropped > > 4.2 - 48 mos - (LTS) No features dropped > > > > > > I think those are probably the two best LTS support release schedules > that follow semver. > > > > Ryan > > > > -- > > 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-develop...@googlegroups.com . > > To post to this group, send email to django-d...@googlegroups.com > . > > Visit this group at http://groups.google.com/group/django-developers. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/f887421b-c470-491f-b5f0-a12af397bfe1%40googlegroups.com. > > > > For more options, v
Re: 1.9 release planning
Quoting semver.org: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. We are only breaking the first rule with backwards incompatible changes that don't undergo deprecations, but considering that we do our very best to avoid these, I think it's fair enough to just document it as a caveat. SemVer makes it easier to see at a glance how long you are supposed to support Django versions as a 3rd-party app author and where you can rely on shims. It also brings more visibility to our efforts to ease straddle two LTS versions (supporting shims from LTS+1 for 1 additional release). I think it's enough to justify adopting it even if we aren't "pure" in its implementation. -- Loïc > On Jun 13, 2015, at 13:03, Tim Graham wrote: > > I'm happy to give it a try if there's consensus that it might help. On the > other hand, this doesn't account for the inevitable backwards incompatible > changes that come along. For example, someone in the survey said "Django 1.7 > is a hard change for clients and it should have been 2.0 so that they realize > what the jump means." Unfortunately, it's impossible to anticipate when > features like that might come along and I'm not sure we'd want to delay > features so that they don't first appear in an LTS release (at least, this > would be a pretty big change in Django development and slow down innovation > in my view). > > On Saturday, June 13, 2015 at 6:25:44 AM UTC-4, Loïc Bistuer wrote: > I think Collin's proposal can match semver without additional overhead when > LTS are the final minor releases of any given major branch. > > 1.8 LTS > 2.0 (Drop features from 1.7) > 2.1 (Drop features from 1.8 LTS) > 2.2 LTS > 3.0 (Drop features from 2.0, 2.1) > 3.1 (Drop features from 2.2 LTS) > 3.2 LTS > > That way we can say that features are never removed until the next major > release. > > Features deprecated in a LTS leak onto x.1 releases but that's fine (1 > release deprecations are a no-go IMO), we can document it as "deprecations > from a major branch will be either loud or gone in the following major > branch". > > -- > Loïc > > > On Jun 13, 2015, at 04:16, Tim Graham wrote: > > > > I'm still in favor of "Collin's proposal." You'll need to convince me that > > keeping deprecations around longer is worth having somewhat meaningful > > version numbers, but I'm not sure I really consider dropping deprecation > > shims as "incompatible API changes" that justify a major version bump. For > > example, if I run on 2.X (whatever is right before the version where > > features are dropped) without deprecation warnings, then upgrading to 3.0 > > isn't any more difficult than other upgrades. It might be a nice touch to > > call the version after the next LTS (2.1 under Collin's proposal) "3.0" > > since it will drop Python 2 support, but it's not really important IMO > > > > On Friday, June 12, 2015 at 8:00:30 PM UTC-4, Ryan Hiebert wrote: > > An alternative would be for the LTS to be the second-to-last minor release > > before a major version bump. > > > > I'm also ignoring the transition for the sake of hypotheticals. I'm also > > assuming that 2.2 is the last release of the 2.X series. > > > > 2.1 - 0 mos - (LTS) No features dropped > > 2.2 - 8 mos - No features dropped > > 3.0 - 16 mos - Drop all features deprecated by 2.1 > > 3.1 - 24 mos - (LTS) No features dropped > > 3.2 - 32 mos - No features dropped > > 4.0 - 40 mos - Drop all features deprecated by 3.1 > > 4.1 - 48 mos - (LTS) No features dropped > > > > It would mean that features deprecated before an LTS cannot be dropped > > until two versions after the LTS, but it fits semver pretty well, and > > doesn't speed up our deprecation removal. > > > > I'd argue for a major version dropping _all_ deprecated features. This has > > the downside of speeding up our removal process in the last version of a > > major release, and it encourages people to stay longer on the release > > previous, since they won't have as much opportunity to fix them. It would > > also mean that features deprecated in the last minor version of a major > > version line would need to skip the pending deprecation warnings. > > > > If it were acceptable to do that, then I'd argue for the LTS to be the > > _last_ in a major version line, rather than the second-to-last. That would > > probably be my overall preferred, though I do recognize the previously > > mentioned drawbacks. Anything deprecated in an LTS in that case would skip > > the pending deprecation warning, and go straight to the deprecation > > warning. The deprecation timeline would then look like this: > > > > 2.2 - 0 mos - (LTS) No features dropped > > 3.0 - 8 mos - All deprecations, including the LTS deprecations, are remo
Re: how to deal with inspect.getargspec() deprecation?
I ended up abstracting our usage of inspect.getargspec() into some utility methods in a django.utils.inspect module. Each method has a separate branch for Python 2 and Python 3. It's not ideal, but I think it's preferable to adding a short-lived dependency or vendored copy, considering that dropping Python 2 in master is < 2 years out. https://github.com/django/django/pull/4846 On Wednesday, June 10, 2015 at 5:45:30 PM UTC-4, Tim Graham wrote: > > The APIs are rather different. I will keep working on the conversions > (we'll need them no matter which option we pick), but here's a flavor: > https://github.com/django/django/pull/4846 > > On Wednesday, June 10, 2015 at 3:50:52 PM UTC-4, Carl Meyer wrote: >> >> On 06/10/2015 01:48 PM, Berker Peksağ wrote: >> > On Wed, Jun 10, 2015 at 9:49 PM, Tim Graham >> wrote: >> >> inspect.getargspec() was deprecated in Python 3.0 and will be removed >> in 3.6 >> >> (ETA late 2016). It started throwing a deprecation warning in Python >> 3.5 >> >> which causes some test failures when we check the number of >> deprecation >> >> warnings so I'd like to deal with it now and avoid introducing more >> usages. >> >> >> >> Its replacement is inspect.signature() which is in all the versions of >> >> Python 3 we support, but not 2.7. Options I see: >> >> 1. Add a dependency for the funcsigs backport [1] (only needed on >> Python 2) >> >> 2. Vendor funcsigs in django.utils (about 1k LOC) (this has been the >> >> historical approach) >> >> 3. Write different code for Python 2 & 3 >> > >> > funcsigs doesn't look like an up-to-date backport and we've fixed many >> > bugs in inspect.signature() in recent releases. It might be safer to >> > go with 3 (instead of adding an unmaintained dependency). >> >> If that's true, then we should write our own backport that covers the >> cases we need (and consider contributing it to six, as Marc suggested). >> We shouldn't rewrite the compatibility code every place we need an >> argument signature (which is how I interpret option 3). >> >> Calr >> >> -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9f638152-1312-4c4b-9f6a-18172b14b12f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: 1.9 release planning
I don't have a strong opinion either way on semver, but I think it's a bit late to rebrand 1.9 as 2.0 considering we've release code and docs with reference to "RemovedInDjango19Warning". Do you have any thoughts on that? We could plan the change for after the next LTS (2.1 -> 3.0) to correspond with the cutover to Python 3. On Saturday, June 13, 2015 at 11:05:49 AM UTC-4, Loïc Bistuer wrote: > > Quoting semver.org: > > Given a version number MAJOR.MINOR.PATCH, increment the: > > MAJOR version when you make incompatible API changes, > MINOR version when you add functionality in a backwards-compatible manner, > and > PATCH version when you make backwards-compatible bug fixes. > > We are only breaking the first rule with backwards incompatible changes > that don't undergo deprecations, but considering that we do our very best > to avoid these, I think it's fair enough to just document it as a caveat. > > SemVer makes it easier to see at a glance how long you are supposed to > support Django versions as a 3rd-party app author and where you can rely on > shims. It also brings more visibility to our efforts to ease straddle two > LTS versions (supporting shims from LTS+1 for 1 additional release). I > think it's enough to justify adopting it even if we aren't "pure" in its > implementation. > > -- > Loïc > > > On Jun 13, 2015, at 13:03, Tim Graham > > wrote: > > > > I'm happy to give it a try if there's consensus that it might help. On > the other hand, this doesn't account for the inevitable backwards > incompatible changes that come along. For example, someone in the survey > said "Django 1.7 is a hard change for clients and it should have been 2.0 > so that they realize what the jump means." Unfortunately, it's impossible > to anticipate when features like that might come along and I'm not sure > we'd want to delay features so that they don't first appear in an LTS > release (at least, this would be a pretty big change in Django development > and slow down innovation in my view). > > > > On Saturday, June 13, 2015 at 6:25:44 AM UTC-4, Loïc Bistuer wrote: > > I think Collin's proposal can match semver without additional overhead > when LTS are the final minor releases of any given major branch. > > > > 1.8 LTS > > 2.0 (Drop features from 1.7) > > 2.1 (Drop features from 1.8 LTS) > > 2.2 LTS > > 3.0 (Drop features from 2.0, 2.1) > > 3.1 (Drop features from 2.2 LTS) > > 3.2 LTS > > > > That way we can say that features are never removed until the next major > release. > > > > Features deprecated in a LTS leak onto x.1 releases but that's fine (1 > release deprecations are a no-go IMO), we can document it as "deprecations > from a major branch will be either loud or gone in the following major > branch". > > > > -- > > Loïc > > > > > On Jun 13, 2015, at 04:16, Tim Graham wrote: > > > > > > I'm still in favor of "Collin's proposal." You'll need to convince me > that keeping deprecations around longer is worth having somewhat meaningful > version numbers, but I'm not sure I really consider dropping deprecation > shims as "incompatible API changes" that justify a major version bump. For > example, if I run on 2.X (whatever is right before the version where > features are dropped) without deprecation warnings, then upgrading to 3.0 > isn't any more difficult than other upgrades. It might be a nice touch to > call the version after the next LTS (2.1 under Collin's proposal) "3.0" > since it will drop Python 2 support, but it's not really important IMO > > > > > > On Friday, June 12, 2015 at 8:00:30 PM UTC-4, Ryan Hiebert wrote: > > > An alternative would be for the LTS to be the second-to-last minor > release before a major version bump. > > > > > > I'm also ignoring the transition for the sake of hypotheticals. I'm > also assuming that 2.2 is the last release of the 2.X series. > > > > > > 2.1 - 0 mos - (LTS) No features dropped > > > 2.2 - 8 mos - No features dropped > > > 3.0 - 16 mos - Drop all features deprecated by 2.1 > > > 3.1 - 24 mos - (LTS) No features dropped > > > 3.2 - 32 mos - No features dropped > > > 4.0 - 40 mos - Drop all features deprecated by 3.1 > > > 4.1 - 48 mos - (LTS) No features dropped > > > > > > It would mean that features deprecated before an LTS cannot be dropped > until two versions after the LTS, but it fits semver pretty well, and > doesn't speed up our deprecation removal. > > > > > > I'd argue for a major version dropping _all_ deprecated features. This > has the downside of speeding up our removal process in the last version of > a major release, and it encourages people to stay longer on the release > previous, since they won't have as much opportunity to fix them. It would > also mean that features deprecated in the last minor version of a major > version line would need to skip the pending deprecation warnings. > > > > > > If it were acceptable to do that, then I'd argue for the LT
Tips on adding a Couchbase backend
Hi folks! I apologize in advance if this is the wrong venue for this discussion I'm trying to determine the best means by which I might be able to add Couchbase (http://www.couchbase.com) support to Django. I've come across something called "django-nonrel" - it seems to have scarce documentation and doesn't seem to have much activity as of late. I've also seen that another non-relational database (Cassandra) has a django backend that bypasses the nonrel fork, though its README (https://github.com/r4fek/django-cassandra-engine) seems to suggest one needs to use cqlengine for this? Admittedly, I'm fairly new to Django itself - though I maintain the Couchbase Python client, and there's been some demand for this feature. In relation to traditional RDBMs, Couchbase has: * SQL-like query language (N1QL) for *searching* (currently JOINS are only supported where one of the sides is a PK). Note this only works for searches, not updates/inserts * CRUD operations * There's also views, but I'm guessing anything expressible as a view can also be expressed in terms of N1QL Can someone point me in the right direction of what to read first? Regards, Mark -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a038e4ce-266d-44a6-a36d-8e2b0d3efbc5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
how long to support Python 3.3?
Django 1.8 was the last version to support Python 3.2, which has its security updates end February 2016. That means Python 3.2 users can continue getting Django security updates for about 2 years after Python security updates end. I am wondering if we should instead try to better align the end of Python support with the end of Django support? (By the way, Django 1.4 supports Python 2.5 which had its security updates end Oct 2011 and since we had trouble configuring Jenkins with Python 2.5, we broke compatibility a couple times in recent security releases -- now I run the tests locally as needed). Let's take Python 3.3 as an example. Security updates for Python 3.3 are scheduled to end in September 2017. Django 1.8 supports 3.3 and will receive updates until April 2018. Given anyone using 3.3 is covered by the LTS, I'm inclined to drop 3.3 support now (in Django 1.9). Alternatively, the next two major releases of Django will be supported until April 2017 and December 2017. I don't find Django support for 3.3 to be a big burden, but there are occasional issues such as new features in 3.4 that are missing and need to be backported for 3.3 (today I ran into a pull request with a need for glob.escape(), so we needed a backport that works on Python 2 and Python 3.3). The other consideration is that Python 3.5 will be released in September, so we'd be back to 3 versions of Python 3 for Jenkins to test against. Are there any users of Python 3.3 out there who find that there are big obstacles to upgrading to 3.4? I think it's useful to plan ahead a bit to try to avoid cases such as the enterprise users who are now stuck on Python 2.6 and Django 1.6. -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5494ca68-c62b-4205-98e1-144471de9d97%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: 1.9 release planning
> On Jun 13, 2015, at 20:43, Tim Graham wrote: > > I don't have a strong opinion either way on semver, but I think it's a bit > late to rebrand 1.9 as 2.0 considering we've release code and docs with > reference to "RemovedInDjango19Warning". Do you have any thoughts on that? We > could plan the change for after the next LTS (2.1 -> 3.0) to correspond with > the cutover to Python 3. Currently we have: 1.8: RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7 RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations from 1.8 master: RemovedInDjango20Warning(DeprecationWarning) - Deprecations from 1.8 RemovedInDjango21Warning(PendingDeprecationWarning) - Deprecations from master In any case, implementing the new policy will require updating warnings from master: RemovedInDjango21Warning needs to become either RemovedInDjango22Warning or RemovedInDjango31Warning with the switch to SemVer. The question is whether it's too invasive to update warnings in a 1.8 patch release. If we ensure that RemovedInDjango19Warning remains importable by aliasing it to RemovedInDjango20Warning(DeprecationWarning), I think it's compatible enough not to delay implementing the scheme by another two years, especially considering how warnings are normally used. But if we want to be super cautious we could just leave the code as it is and document the problem in the 1.8 release notes, after all we are extending the lifespan of the shims (at least in appearance) which isn't as problematic as if we were shortening it. -- Loïc -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3B8CE3F8-F39C-49AF-A5B5-7A252E9F7CAD%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: 1.9 release planning
Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs reference Django 1.9. I'm not enthusiastic about updating all that. On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote: > > > > On Jun 13, 2015, at 20:43, Tim Graham > > wrote: > > > > I don't have a strong opinion either way on semver, but I think it's a > bit late to rebrand 1.9 as 2.0 considering we've release code and docs with > reference to "RemovedInDjango19Warning". Do you have any thoughts on that? > We could plan the change for after the next LTS (2.1 -> 3.0) to correspond > with the cutover to Python 3. > > > Currently we have: > > 1.8: > RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7 > RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations > from 1.8 > > master: > RemovedInDjango20Warning(DeprecationWarning) - Deprecations from 1.8 > RemovedInDjango21Warning(PendingDeprecationWarning) - Deprecations > from master > > In any case, implementing the new policy will require updating warnings > from master: RemovedInDjango21Warning needs to become either > RemovedInDjango22Warning or RemovedInDjango31Warning with the switch to > SemVer. > > The question is whether it's too invasive to update warnings in a 1.8 > patch release. If we ensure that RemovedInDjango19Warning remains > importable by aliasing it to RemovedInDjango20Warning(DeprecationWarning), > I think it's compatible enough not to delay implementing the scheme by > another two years, especially considering how warnings are normally used. > But if we want to be super cautious we could just leave the code as it is > and document the problem in the 1.8 release notes, after all we are > extending the lifespan of the shims (at least in appearance) which isn't as > problematic as if we were shortening it. > > -- > Loïc > > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1213b5f4-e7f2-4326-9962-13afa313e554%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Django Admin - ModelAdmin exclude
I agree there are many ways to accomplishing things in the admin, but cleaning that up and continuing BC is a completely other ticket / implementation (it looks like a good Sumer of Code project similar to the Meta API recently completed). Since the ticket was marked as accepted, I'll double check my patch and make a PR this week. -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a7d259f5-e54f-4511-825c-93e8f4cd3de8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Tips on adding a Couchbase backend
There's nothing in the way of official documentation about writing third-party database backends. I guess the best approach would be to look through the source code of database engines in Django as well as the projects you mentioned and learn from that. If we can add any hooks to Django to help out your effort, let us know. On Saturday, June 13, 2015 at 5:14:40 PM UTC-4, Mark Nunberg wrote: > > Hi folks! > > I apologize in advance if this is the wrong venue for this discussion > > I'm trying to determine the best means by which I might be able to add > Couchbase (http://www.couchbase.com) support to Django. I've come across > something called "django-nonrel" - it seems to have scarce documentation > and doesn't seem to have much activity as of late. I've also seen that > another non-relational database (Cassandra) has a django backend that > bypasses the nonrel fork, though its README ( > https://github.com/r4fek/django-cassandra-engine) seems to suggest one > needs to use cqlengine for this? > > Admittedly, I'm fairly new to Django itself - though I maintain the > Couchbase Python client, and there's been some demand for this feature. > > In relation to traditional RDBMs, Couchbase has: > > * SQL-like query language (N1QL) for *searching* (currently JOINS are > only supported where one of the sides is a PK). Note this only works for > searches, not updates/inserts > * CRUD operations > * There's also views, but I'm guessing anything expressible as a view can > also be expressed in terms of N1QL > > Can someone point me in the right direction of what to read first? > > Regards, > Mark > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9a40b301-0b6c-405d-99bb-c3ba861e7c2b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Fellow Report - June 13, 2015
In non-code work, the discussions about the future release schedule
continue in the "1.9 release planning" thread. I hope we can finalize that
within the next week or so.
Report for week ending June 13, 2015:
Triaged
---
https://code.djangoproject.com/ticket/24948 - BMP Image File treated as
invalid (accepted)
https://code.djangoproject.com/ticket/24960 - Blank pages due to {{
block.super }} (worksforme)
https://code.djangoproject.com/ticket/24962 - Objects with primary keys
containing newlines do not get links to being edited in the admin list view
(accepted)
https://code.djangoproject.com/ticket/24951 - Error deleting from table
with Foreign Key being Primary Key at the same point (accepted)
https://code.djangoproject.com/ticket/24940 - unhashable type:
'RelatedManager' when deleting a model using django admin that has
GenericRelation and related_query_name (accepted)
https://code.djangoproject.com/ticket/24954 - Adding an explicit UUID id
doesn't change type of ManyToMany fields pointing to it (accepted)
https://code.djangoproject.com/ticket/24976 - admin.TabularInline custom
form field header displaying as None on admin page (accepted)
https://code.djangoproject.com/ticket/24980 - Calendar selector for
DateField defaults to wrong date when timezone is missmatching (accepted)
https://code.djangoproject.com/ticket/24981 - Importing an abstract model
from a bare package fails. (invalid)
Authored
https://github.com/django/django/commit/c19bc2d5d49f373b274772fa6cd936dfd05761e7
- Fixed tests from refs #24922 when run in reverse.
https://github.com/django/django/pull/4831 - Fixed tests for refs #24767 on
databases that don't support microseconds.
https://github.com/django/django/pull/4833 - Minor edits to password
validation tests/docs (refs #16860).
https://github.com/django/django/pull/4841 - Fixed #24903 -- Fixed
assertRaisesMessage on Python 2.7.10.
https://github.com/django/django/pull/4852 - Added ALLOWED_HOSTS and
SERVER_EMAIL details to deployment checklist.
https://github.com/django/django/pull/4846 - Fixed #24979 -- Removed usage
of inspect.getargspec().
https://github.com/django/djangoproject.com/pull/489 - Added admin password
reset
https://github.com/django/djangoproject.com/commit/b7ee1f9da1203c4b22085e4ee057c170ddad38e5
- Removed duplicate URL prefix in password reset email
Reviewed/committed
--
https://github.com/django/django/pull/4724 - Refs #21927 -- Made
application and instance namespaces more distinct.
https://github.com/django/django/pull/4814 - Fixed #24796 -- Added a hint
on placement of SecurityMiddleware in MIDDLEWARE_CLASSES.
https://github.com/django/django/pull/4790 - Fixed #24929 -- Allowed
permission_required decorator to take any iterable
https://github.com/django/django/pull/4781 - Fixed #24769 -- Cast optparse
verbosity argument to an integer for better backwards compatibility.
https://github.com/django/django/pull/4849 - Fixed #24968 -- Removed bad
horizontal scrollbar appearing on admin changelist page.
https://github.com/django/django/pull/4750 - Refs #24125 -- Added
admin_docs tests for multiple template engines
https://github.com/django/django/pull/4842 - Fixed #24963 -- Added
File.seekable() on Python 3.
https://github.com/django/django/pull/4843 - Fixed #24965 -- Made
LiveServerTestCase.live_server_url accessible from class
https://github.com/django/django/pull/4855 - Fixed #24978 -- Escaped
special characters in fixture paths
https://github.com/django/django/pull/4740 - Fixed #24890 -- Added warning
to collectstatic when static files have clashing names
https://github.com/django/djangoproject.com/pull/485 - Improved
documentation footer display.
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/eb6fe6ac-e40a-4825-bfcc-3277aec815cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Tips on adding a Couchbase backend
On Sunday 14 June 2015 00:13:33 Mark Nunberg wrote: > Hi folks! > > I apologize in advance if this is the wrong venue for this discussion > > I'm trying to determine the best means by which I might be able to add > Couchbase (http://www.couchbase.com) support to Django. I've come across > something called "django-nonrel" - it seems to have scarce documentation > and doesn't seem to have much activity as of late. I've also seen that > another non-relational database (Cassandra) has a django backend that > bypasses the nonrel fork, though its README > (https://github.com/r4fek/django-cassandra-engine) seems to suggest one > needs to use cqlengine for this? > In addition to Tim's notes, please consider that django-cassandra-engine is not a database-engine in the regular sense -- it does not seem to support Django models, but only cqlengine models. You can probably use it to build a Cassandra-based web application, utilizing Django's request-handling facilities and other non-database-related utilities, but you will not be able to use most of the Django eco-system. From your description, it is not clear to me if you can do better for CouchBase, but perhaps you can. You may also want to look at a project called django-mailer[1], which is an example of "faking" Django models -- that is, taking something which isn't a Django model (in this case, mail messages) and wrapping it in enough API to allow it to be used in the Django admin. This practice is officially supported since Django 1.8, which made the model metadata APIs public. HTH, Shai. [1] https://github.com/PirosB3/django-mailer
