aber hoffentlich bleibt die API jetzt mal stabil. Von 0.96 zu 0.97 zu 1.0beta haben sich jeweils immer wesentliche (kleinere) Dinge geändert, dass alter Code nicht mehr lief.
Was soll den das für ne schwachsinnige Ausrede sein. Wenn du bei jeder gcc Version dein Programm anpassen müsstest, damit du es kompilieren könntest, das wäre genauso schwachsinnig, da kann ich dann viel in die Doku schreiben.
Wenn man will, dass irgendjemand mit dem Framework arbeitet, dann muss man schon dafür sorgen, dass die Anwender so ein Framework mal ein/zwei Jahre verwenden können ohne dass man seinen Code anpassen muss.
Ich hab Django noch nicht eingesetzt, aber wenn man hört, dass hier bei Minor Versionen Änderungen im eigenen Code erforderlich sind, dann bin ich froh, dass ich mich noch nie damit befasst habe:-)
Ich nehme an, dass auf der Web-Site die Warnung stand, dass sich die API sehr wahrscheinlich noch ändern kann, solange es nicht 1.0 ist. Das ist normal und vollkommen ok. Ab der 1.0 sollte es dann stabiler sein, damit man es wirklich sinnvoll einsetzen kann. Hat also nichts mit Ausrede zu tun.
So lange dies nur während den unstable releases (<1.0) vorkommt, ist das meines Erachtens voll ok. Das gehört zu den kleinen Einschränkungen, die man in Kauf nehmen muss, wenn man unstable releases bereits produktiv einsetzen will.
Es ist mit 1.0 die erste stabile Version erschienen, vorher waren API Änderungen vorher deutlich angekündigt.
Macht z.B. Qooxdoo auch nicht anders. Sie sind erst bei 0.8, und haben zwischen 0.7 und 0.8 extrem viel geändert. Wenn sie das nicht machen würden hätten sie heute noch den mist aus dem ersten öffentlichen Release.
Von Felix Schwarz am Sa, 6. September 2008 um 12:31 #
Da aber Django etwa zwei Jahre kein stabiles Release veröffentlicht hat, die Doku auf der Webseite sich auf die SVN-Versionen bezog und in den User-Foren fast immer dazu geraten wurde, auf jeden Fall die SVN-Version einzusetzen, ist dies schon eine berechtigte Kritik. Allerdings nicht an den API-Änderungen, sondern an der grauenhaften Release-Politik von Django bisher, da man praktisch nur die SVN-Versionen einsetzen konnte. Hoffentlich wird sich das mit dem Release der 1.0-Version in Zukunft ändern.
Mir ist schon klar, dass 0.x nicht 1.x ist. Aber nervig wars trotzdem, zumal man in Debian alle drei Versionen vertreten hatte je nach Distribution. Weiterhin machen sie pydoc kaputt: $ pydoc django.db problem in django.db - : Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined.
$ pydoc -k suchwort Traceback (most recent call last): File "/usr/bin/pydoc", line 5, in pydoc.cli() [snip] File "./django/contrib/gis/geos/libgeos.py", line 52, in '", "'.join(lib_names)) django.contrib.gis.geos.error.GEOSException: Could not find the GEOS library (tried "geos_c"). Try setting GEOS_LIBRARY_PATH in your settings.
Von Felix Schwarz am Sa, 6. September 2008 um 20:42 #
Mir ist schon klar, dass 0.x nicht 1.x ist. Aber nervig wars trotzdem, zumal man in Debian alle drei Versionen vertreten hatte je nach Distribution.
Natürlich ist das nervig. IMHO war die Release-Politik bisher bei Django der größte Kritikpunkt überhaupt. Denn dadurch mussten User sich regelmäßig mit API-Änderungen herumschlagen. Ich kann deine Frustration wirklich gut verstehen.
Mich hat das zum Glück nur wenig betroffen, da ich viel mehr mit TurboGears arbeite :-)
Von Anonymer Feigling am Mo, 8. September 2008 um 02:24 #
Natürlich ist das nervig. IMHO war die Release-Politik bisher bei Django der größte Kritikpunkt überhaupt. Denn dadurch mussten User sich regelmäßig mit API-Änderungen herumschlagen. Ich kann deine Frustration wirklich gut verstehen.
Naja, ich muss sagen, dass die API-Änderungen eigentlich nur Mitte August bis 1.0 wirklich häufig waren. Und generell war die größte Änderung Newforms-Admin, aber es war von Anfang an klar, dass jeder der da tief drin rumgräbt, früher oder später den Kram neu schreiben muss.
Zum Vergleich erinnere ich an TurboGears 0.7 -> 0.8.
Von Felix Schwarz am Mo, 8. September 2008 um 10:43 #
Es geht mir weniger um die API-Änderungen an sich, als vielmehr darum, dass die meisten Anwender kaum eine Chance hatten, ihnen zu entgehen, weil es so lange kein stabiles Release gab. Und die meisten mir bekannten Django-User mussten z.B. bei newforms-admin einiges umstellen, weil man eben häufig nicht mit den defaults auskommt.
Bei TurboGears gibt es dagegen regelmäßige Releases und wer "einfach nur stable" haben will, wird auch nicht mit einer zwei Jahre alten Version abgespeist, die von der Community praktisch nicht mehr supported wird.
Was soll den das für ne schwachsinnige Ausrede sein. Wenn du bei jeder Kernel-Version deinen Treiber anpassen müsstest, damit du es kompilieren könntest, das wäre genauso schwachsinnig, da kann ich dann viel in die Doku schreiben.
Wenn irgendwas in der Linux-Welt eine stabilere API braucht, dann ist es der Kernel. Wollte ich nur einmal anmerken.
Was soll den das für ne schwachsinnige Ausrede sein. Wenn du bei jeder gcc Version dein Programm anpassen müsstest, damit du es kompilieren könntest, das wäre genauso schwachsinnig, da kann ich dann viel in die Doku schreiben.
Wenn man will, dass irgendjemand mit dem Framework arbeitet, dann muss man schon dafür sorgen, dass die Anwender so ein Framework mal ein/zwei Jahre verwenden können ohne dass man seinen Code anpassen muss.
Ich hab Django noch nicht eingesetzt, aber wenn man hört, dass hier bei Minor Versionen Änderungen im eigenen Code erforderlich sind, dann bin ich froh, dass ich mich noch nie damit befasst habe:-)
Macht z.B. Qooxdoo auch nicht anders. Sie sind erst bei 0.8, und haben zwischen 0.7 und 0.8 extrem viel geändert. Wenn sie das nicht machen würden hätten sie heute noch den mist aus dem ersten öffentlichen Release.
Das wäre völlig unsinnig.
$ pydoc django.db
problem in django.db - : Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined.
$ pydoc -k suchwort
Traceback (most recent call last):
File "/usr/bin/pydoc", line 5, in
pydoc.cli()
[snip]
File "./django/contrib/gis/geos/libgeos.py", line 52, in
'", "'.join(lib_names))
django.contrib.gis.geos.error.GEOSException: Could not find the GEOS library (tried "geos_c"). Try setting GEOS_LIBRARY_PATH in your settings.
Tolle Sache :(.
Natürlich ist das nervig. IMHO war die Release-Politik bisher bei Django der größte Kritikpunkt überhaupt. Denn dadurch mussten User sich regelmäßig mit API-Änderungen herumschlagen. Ich kann deine Frustration wirklich gut verstehen.
Mich hat das zum Glück nur wenig betroffen, da ich viel mehr mit TurboGears arbeite :-)
fs
Naja, ich muss sagen, dass die API-Änderungen eigentlich nur Mitte August bis 1.0 wirklich häufig waren. Und generell war die größte Änderung Newforms-Admin, aber es war von Anfang an klar, dass jeder der da tief drin rumgräbt, früher oder später den Kram neu schreiben muss.
Zum Vergleich erinnere ich an TurboGears 0.7 -> 0.8.
Bei TurboGears gibt es dagegen regelmäßige Releases und wer "einfach nur stable" haben will, wird auch nicht mit einer zwei Jahre alten Version abgespeist, die von der Community praktisch nicht mehr supported wird.
fs
Wenn irgendwas in der Linux-Welt eine stabilere API braucht, dann ist es der Kernel. Wollte ich nur einmal anmerken.