Github tags
Hi, Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5 alpha tagged on the github repository? The tagging seems to have fallen behind with these releases. Thanks, -- Matt -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 1.9 release planning
On 11 June 2015 at 01:37, Collin Anderson wrote: > > I'd propose something slightly different, that's very close to our current > deprecation timeline: > 1.8 (LTS): No features dropped. > 1.9: Dropped features deprecated in 1.5, 1.6, 1.7 > 2.0: Dropped features deprecated in 1.8 > 2.1 (LTS): No features dropped. > 2.2: Dropped features deprecated in 1.9, 2.0 > 2.3: Dropped features deprecated in 2.1 > > Seems to me features deprecated in an LTS are fair game to disappear in the > next LTS. This allows us to remove "dotted paths in reverse() and url()" > because that's deprecated in 1.8. > > If we can guarantee compatibility between LTSs, I think that would be a huge > win, at the cost of extending the removal of some deprecated features by one > release (8 months). > Hi everyone, Sorry to stick my nose in, but thought I might throw a potential spanner-in-the works with this release discussion, in regard to version naming. I understand that the current version system doesn't have too much inherent meaning, and that 2.0 will come after 1.9 'just so we don't stay on 1.x forever'. With a more structured release plan, and LTS releases, would it be worth considering LTS releases as 'major' version numbers, with regular releases and 'minor' version releases? It would be easier to identify LTS releases at a glance, and might provide more meaning to the versioning scheme? Feel free to shut this idea down if it's going to open a can-of-worms :) Cheers, -- Matt -- 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/CACATwqQge_4Bx%2BctJFsf02uTyhu9gy4GMBaUHx23XUEY6yXCuw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Possible breakage of queryset week_day lookup - potential 1.6 release blocker?
I discovered today that unless timezone data is loaded in to mysql, then previously working (although functionally broken) week_day lookups return an empty queryset. I couldn't find notes in the docs (release notes or queryset week_day docs) that mention this requirement - but happened to read the docs for the new datetimes() behaviour and then discovered how to load tzinfo in to mysql. I filled a ticket to update the docs: https://code.djangoproject.com/ticket/21095 I am happy to contribute modifications to the docs - but before I do, I thought it might be worth seeing if this is the correct approach. Should an empty list be the desired behaviour, should an exception be raised, or should the old behaviour (which doesn't honour timezones) be maintained when tzinfo is not available? -- Matt m...@mattaustin.me.uk http://mattaustin.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: Possible breakage of queryset week_day lookup - potential 1.6 release blocker?
Hi Aymeric, On 12 September 2013 18:16, Aymeric Augustin wrote: > Can you confirm that your project has the USE_TZ setting set to True? Yes, USE_TZ is True, pytz is installed, and default timezone is set to UTC. > I believe I introduced it with a patch that made the date lookups (__year, > __month, __day, __week_day) take the time zone into account. Previously they > would consider the date in UTC when USE_TZ = True, which returned incorrect > results. Since this was a bugfix, I didn't mention it in the release notes. > > The problem probably affects all four date lookups. If you have time to test > this, it would help. I've tried the lookups on a new mysql installation (no tzinfo loaded), and '__month', '__day', and '__week_day' lookups all cause an empty queryset to be returned. However, '__year' does appear to return the correct results. Thanks for investigating. -- Matt -- You received this message because you are subscribed to the Google Groups "Django developers" 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. For more options, visit https://groups.google.com/groups/opt_out.
