Skip to content

Commit 7c87a17

Browse files
authored
Merge pull request #60 from django/timeline-additions
Add 1.5, 1.6 and South timeline entries
2 parents e1985d7 + 3a5e72e commit 7c87a17

File tree

5 files changed

+44
-1
lines changed

5 files changed

+44
-1
lines changed

content/timeline/00_template.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,7 @@ params:
1010
# milestone = universal milestone of Django/community
1111
# personal = a personal reflection
1212
# release = a django release
13+
# app = significant external app (like South)
1314
timeline_type: milestone
1415

1516
# If it's a release, you can add:
Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
---
2+
title: "South 0.2 released"
3+
date: "2017-12-02"
4+
draft: false
5+
6+
params:
7+
timeline_date: 2008-08-09
8+
timeline_type: app
9+
10+
---
11+
12+
Django South 0.2 [is released](https://web.archive.org/web/20080831004106/http://south.aeracode.org/wiki/About) by Andrew Godwin. It notably becomes the migration framework for Django for many years (until Django 1.7 is released in 2014). If you were using Django between 2008 and 2014, you most likely also used South:
13+
14+
> Django has always made use of automatic schema generation - the almost-famous "syncdb" that must be run at least once (and often more) on every Django project. If you've ever used Django on a resonably large project, you quickly discover that you're deleting tables and regenerating them if you change schema - and that's only if you're in development, and can afford to possibly lose data.
15+
>
16+
> Other frameworks, such as the infamous Ruby on Rails, have migrations, which incrementally build up a schema as a series of migrations are executed, the idea being that a schema change is simply one more migration. South is an attempt to bring migrations over to Django, but in a more robust and useable way.
Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
---
2+
title: "Django version 1.5"
3+
date: "2017-12-02"
4+
draft: false
5+
6+
params:
7+
timeline_date: 2013-02-26
8+
timeline_type: release
9+
timeline_release: "1.5"
10+
11+
---
12+
13+
Django 1.5 is released with support for a swappable User model, and the first Django release to support Python 3 (in an experimental way), and `update_fields` is introduced to specify which fields should be saved on a model.
Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
---
2+
title: "Django version 1.6"
3+
date: "2017-12-02"
4+
draft: false
5+
6+
params:
7+
timeline_date: 2013-11-06
8+
timeline_type: release
9+
timeline_release: "1.6"
10+
11+
---
12+
13+
Dedicated to Malcolm Tredinnick (RIP 🕯️), Django 1.6 now officially supports Python 3 and it modernizes the `startproject` and `startapp` commands. Under the hood, persistent database connections are introduced to reuse the same db connection across multiple requests and a call to a Model's `save()` now requires just 1 database query instead of 2.

content/timeline/2014-09-02-django-1.7.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,6 @@ params:
1010

1111
---
1212

13-
Django will have migrations! This is perhaps the most well-known Django release, as South is replaced by a built-in migration framework. All Django projects will have to adapt, but the benefits are huge.
13+
Django will have migrations! This is perhaps the most well-known Django release, as South is replaced by a built-in migration framework. All Django projects will have to adapt, but the benefits are huge. South becomes the blueprint for the built-in migrations feature, which is lead once again by Andrew Godwin.
1414

1515
But that isn't the only big change: 1.7 also introduces the Application registry (an optional `apps.py` for applications), the system checks framework, as well as the widely popular `QuerySet.as_manager()` shortcut.

0 commit comments

Comments
 (0)