March 8, 2013
Tags: 1.1.1, django, extensions
Another bugfix release of Django-Extensions hits the deck.
ChangeLog:
March 2, 2013
Tags: 1.1.0, django, extensions
We just released version 1.1.0 of Django-Extensions.
This version brings initial support for both Django 1.5 and Python 3.3 !
Thanks to fhahn and Mikolaj Romel for their help on this.
ChangeLog:
January 27, 2013
Tags: 1.0.3, django, extensions
A new version of Django-Extensions just hit PyPi :)
We call it: 1.0.3
ChangeLog:
December 16, 2012
Tags: 1.0.2, django, extensions
Minor version update Django-Extensions 1.0.2 is out.
This release fixes the following problems:
tests: fix keyzcar test failure:
ImproperlyConfigured: You must set the ENCRYPTED_FIELD_KEYS_DIR setting to your Keyczar keys directory.
fields: fix docstring for UUID
docs: Make README links clickable and organized.
show_urls: Revive --unsorted option
Added LoggingBaseCommand that logs run time errors to Python logger django.commands
November 8, 2012
Tags: 1.0.1, django, extensions
Minor version update Django-Extensions 1.0.1 is out.
This release fixes the following problems:
October 22, 2012
Tags: 1.0, django, extensions
So it finally happened, Django-Extensions 1.0 is out.
After getting a lot of feedback from the community, I decided to call it 1.0.
Discussions about going fully on-par with Django on version numbering was very interesting and the nice thing about a 1.0 release is that we can always do that later. For now having 1.0 is good enough and besides if we would have called it 1.4 now we never would have been able to celebrate the 1.0 release ;)
Please all start testing this release so we can iron out any small issues left as soon as possible.
Some highlights of the changes in this release are:
September 20, 2012
Tags: django, extensions, versioning
After my previous post http://trbs.net/blog/2012/09/19/django-extensions-version-010-or-10/ and the many positive reactions I would like to suggest a third option.
I didn't include this before because I wasn't yet sure if it would be a good option. But after some more thinking and reading Christophe31's suggestion which is very similar I think we should look seriously at the option :-)
The idea is that we make Django Extensions follow the Django version numbers closely. This would mean bumping the version number to 1.4.
With this scheme we would commit to the following in Django Extensions:
* Django-Extensions 1.4 is compatible with Django 1.4 and it's deprecation timeline. * Django-Extensions will deprecate and update code on par with Django. (This would help us fix aka remove the tons of legacy/backwards compatibility hacks in the codebase) * A new version with bumped version number is released as soon as possible after a Django release.
For a user it should be intuitive and clear that you should match the major version numbers of Django-Extensions to whatever version of Django you are using. This also solves questions like what version will support Python-3 or PyPy or deprecates using feature X.
Some details would still need to be worked out... like either use our own patch versions or add a different indicator for differentiating between updates to Django Extensions. For example both of these version numbers could indicate the first update to a Django 1.4 compatible extensions release:
* Django-Extensions 1.4.1 * Django-Extensions 1.4p1
As always leave your votes, thoughts, comments, rants (really, please don't :-) ) or pony's at:
https://github.com/django-extensions/django-extensions/issues/241
September 19, 2012
Tags: django, extensions
We are getting close to releasing a new version of Django Extensions to PyPi which means it's about time to bump the version number once again.
Right now our version number is at 0.9 so the question becomes what do we use next ? We can go and continue to increment with +0.1 which will make this the 1.0 release.
The thing for me with Django Extensions is that it's more a continuous process then something with 'stable' releases.
What I mean is that as a collection of extensions there is really no such thing as a 'stable api/abi' as there is in a framework codebase like Django itself.
So I don't mind either way. We can call it 1.0 and just increment that as long as we don't make any radical or major changes to the code base. Or just continue with the 0.x numbering for the time being.
Please put your vote and/or thoughts about this in a comment at:
https://github.com/django-extensions/django-extensions/issues/241
January 23, 2010
Tags: django, history, models, tables, unpickled
I've uploaded a new version of django-history-tables [1] to the mercurial repository. It now should run on Django 1.0 + 1.1 and finally supports (although basically) the Admin interface.
For those that don't know django-history-tables (guessing that's 99.9% of everybody reading this), it is a pluggable Django application to create addition tables inside the database recording the history of changes and deletion of Django models.
This in itself is not unique there are many more project out there doing basically the same but most implement this by serializing data (such as pickling, json, xml, etc). Big drawback of this approach is that when schema changes your serialized history does not change with it. Somewhere down the line when you have forgotten all the schema changes it will be most difficult to use this history data.
django-history-tables works by using one additional 'normal' database table to store history information; major benefit of this approach is that there's no pickling, no serializing, and it should be able to support anything that your database supports as well.
Schema changes in this approach needs to be applied to both tables. When you change your model, you will need to change the schema of the history table as well. <shameless-plug>By using my sqldiff extensions in django-extensions this process can be made pretty easy.</shameless-plug>
In the future I hope to support the major schema migration tools for Django so that we can make schema changes in the history models even less painful.
It has been a while since I've worked on django-history-tables and truth be told I kinda forgot about it :-) It's been lingering in a corner for a while now and I've been busy doing other things like maintaining django-extensions and writing news sites in Django.
But then something really cool happened, something which is really telling for Open Source projects and the Open Source community as a hole. Somebody contacted me, out of the blue, an email from a stranger with the message that they had updated my old proof-of-concept code to run on new versions of Django with the patch attached.
We started talking and found that other people had written patches for it as well and put them up on the issue tracker at Google code. A project which was, for all intents and purposes dead to me, suddenly sparked back to live.
This inspired me to get to work again and to try to get the project back into some kind of shape.
Now it's not perfect yet, it will have bugs and needs more work. I can also do with some help improving it, making it better and reviewing that the implementation works as expected.
So please try it, play with it, have fun with it. And if you like it leave a message :)
| [1] | Django History Tables: http://code.google.com/p/django-history-tables/ |
July 11, 2009
Tags: app, bookmarks, code, django, hg, network, reusable, social
The Django Social Bookmarks app does what you might expect this application to do.
It provides an easy and reusable way to get those pesky add to this social network site on a Django site.
It currently supports 34 different sites, ranging from the big ones like; twitter, facebook, slashdot, delicious, digg, technorati, strumble to local networks like nujij (Dutch), ekudos and tagmos or netjes (Belgium).
All texts in the app use Django i18n so people should have no trouble contributing both links and translations to make it truly comprehensive.
After adding social_bookmarks to INSTALLED_APPS and making sure the images are reachable you can use the provided inclusion-tag to add the links in a template.
Template example:
{% load social_bookmarks_tags %}
<div class="content">
{{ content }}
{% show_social_bookmarks object.title object.get_absolute_url %}
</div>
The default inclusion-tag template specifies some simple css classes so you can theme the links without having to write you own template.
CSS:
/* div around the entire block of links ^/
.socialbookmarks {
display: block;
}
.socialbookmarks strong {
font-weight: bold;
color: black;
}
/* individual links */
.socialbookmarks .social {
color: #ccc;
}
/* no borders on images */
.socialbookmarks .social a img {
border: 0px;
}
Hopefully it is useful for other people and project as well. If you want to use this in your own project, contribute with links, translations or idea please drop me a line at bitbucket or #django irc.
