Sorry if these questions are getting boring since everyone wants to know when the next release (and 1.0) is released .. but i haven't found a answer by searching the forums... After so many backward incompatible changes it would be really nice if there would be a new django release. I want people to use my project (SCT: Sphene Community Tools) but i'm not able to keep up two versions and backport all new features.. it is kind of understandable that not everyone wants to use the latest trunk just to use SCT... (There are currently many problems - i managed to keep up with the newforms clean_data vs. cleaned_data change, but with dozen of other changes and new features i really want/need to use i gave up to support the latest django release.. I'm not asking that there are fewer API changes in django or whatever, just that there is a reasonable django release i can make SCT compatible with.)
So are there any plans on releasing a 0.97 ? I hope you understand my concerns - django is really great and the trunk is stable but 1.) there are many users who don't want to use the latest development version from the trunk (or are too lazy to install a svn client - most of the times it is faster to simply click a download url) 2.) i can't create releases for my own software.. it would be ridiculous to create a release which has a dependency on 'the latest development version' .. since this dependency can break every time someone commits something into the django trunk..
> So are there any plans on releasing a 0.97 ? I hope you understand my > concerns - django is really great and the trunk is stable but
I understand the concern, but how does having a 0.97 release change this for you? There would still be potentially backwards-incompatible changes moving forward from 0.97 to the next official release.
If you just want to be able to announce which snapshot of the Django trunk your application supports, you could point to the svn release number (e.g. app supports Django trunk svn release #6650 and that future releases are not guaranteed to work.)
On Nov 8, 10:53 pm, RajeshD <rajesh.dha...@gmail.com> wrote:
> I understand the concern, but how does having a 0.97 release change > this for you? There would still be potentially backwards-incompatible > changes moving forward from 0.97 to the next official release.
of course there will be backwards-incompatible changes afterwards .. but it would be much easier to keep up with those.. or support both.. i'm not sure when 0.96 was released, but probably >7 months ago .. if there would be an 0.97 release i could create a SCT release and probably stay compatible with django for a couple of months ..
> If you just want to be able to announce which snapshot of the Django > trunk your application supports, you could point to the svn release > number (e.g. app supports Django trunk svn release #6650 and that > future releases are not guaranteed to work.)
as far as i understand it, django applications are ment to be pluggable.. how big are the odds that you'll find two applications which would work with the same django trunk revision ? SCT is not (just) meant as a final product which runs separately, but as applications which can be integrated into a django project.. i can't force people to use a given revision .. having a release which holds for 2-4 months would make things easier imho ..
> as far as i understand it, django applications are ment to be > pluggable.. how big are the odds that you'll find two applications > which would work with the same django trunk revision ?
I didn't mean that your app would stop working at all on any other revisions. Just that you can "officially certify" that it's known to work with a certain revision (that you've had a chance to test). Your users can still use it with future revisions (see below for more thoughts on this.)
> SCT is not (just) meant as a final product which runs separately, but > as applications which can be integrated into a django project.. i > can't force people to use a given revision .. having a release which > holds for 2-4 months would make things easier imho ..
Not every new trunk commit creates a backward incompability problem. Furthermore, there are around 4 changes a month that are backward- incompatible (based on the list here: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges) and not all of them affect everyone who's using a trunk release.
As an example, the change from FloatField to DecimalField in trunk revision 5302 would only prevent your app from working if your app has models that use that field.
Perhaps, you want to consult with other app writers (django-tagging, django-voting, registration, etc.) and see how they handle this issue.
The next release will almost certainly be written as "1.0".
Making releases isn't a trivial thing. Along with the stabilisation period prior to a release, there's the implicit "end-of-life" impact on older releases: 0.91 would no longer be in the security updates path. 0.96 users would no longer get the benefit of "new in development version" markers in the documentation (which is how a 0.96 user can tell that the next bit of documentation doesn't apply to them, but they can otherwise use the current documentation, with all the updates and fixes it includes). Everybody has to think about doing the upgrade dance.
It's a lot of work to make a release and has wide impact, both good and bad. So we're focusing on making 1.0 the next "big impact" point. Yes, it's not always going to be convenient for people as the gap between the last release and trunk gets ever-wider. That's a problem on every project. If you want to release stuff that works for everybody in circumstances like that, you're unfortunately going to have to think about having two versions for a while.
Developing software has these sorts of problems. We all realise that and there's no solution that suits everybody. Bear with us for a bit as we work towards 1.0. Trust me on this: the maintainers want to get it out the door as much as you do.
On Nov 9, 2:58 am, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> work towards 1.0. Trust me on this: the maintainers want to get it out > the door as much as you do.
i'm sure they do .. but my "fear" (or .. guess) is that it might be more important to be bug-free and stable for such a big milestone as a 1.0 release (especially if the promise is that it should be API-stable afterwards), that there won't be one for another year ..
anyway, thanks for your responses, i'll simply recommend everyone to use the trunk version as long as there is no new django release ..
> The next release will almost certainly be written as "1.0".
Bad news. We have a policy to use only published versions of libraries, so our way from 0.96.x to all sweet improvements like unicode will be longer...
On Nov 9, 2007 11:07 AM, Jarek Zgoda <jarek.zg...@sensisoft.com> wrote:
> Malcolm Tredinnick napisał(a):
> The next release will almost certainly be written as "1.0".
> Bad news. We have a policy to use only published versions of libraries, > so our way from 0.96.x to all sweet improvements like unicode will be > longer...
Basically, the current policy means that they're doing lots of different releases - every trunk revision is a release :-(
At least, that's how I see it when one app is written against rxxxx, another against ryyyy...
Surely if it's stable enough to recommend to people that they just use trunk, it's stable enough to release a 0.97? Any huge issue that comes up can always be a 0.97.x. All the objections earlier also apply to people using trunk.
On Fri, 2007-11-09 at 12:05 +0100, Remco Gerlich wrote: > On Nov 9, 2007 11:07 AM, Jarek Zgoda <jarek.zg...@sensisoft.com> wrote:
> > Malcolm Tredinnick napisał(a): > > The next release will almost certainly be written as "1.0".
> > Bad news. We have a policy to use only published versions of libraries, > > so our way from 0.96.x to all sweet improvements like unicode will be > > longer...
> Basically, the current policy means that they're doing lots of > different releases - every trunk revision is a release :-(
> At least, that's how I see it when one app is written against rxxxx, > another against ryyyy...
You're entitled to view it that way, but it's not at all accurate. Plenty of code will run against many, many revisions simultaneously. This was addressed in a reply earlier in this thread.
> Surely if it's stable enough to recommend to people that they just use > trunk, it's stable enough to release a 0.97? Any huge issue that comes > up can always be a 0.97.x. All the objections earlier also apply to > people using trunk.
You write as if making a release is zero effort. Also as if I didn't even write my original reply where I outlined some of the reasons why making a release isn't zero impact for both the maintainers and the users.
In my earlier reply, I also addressed how it's possible to have an application that runs against both 0.96 and trunk's HEAD, or near to it. It's called parallel releases and is a very common software practice.
Finally, for everybody who feels that they really want to write something in this thread about why there should be a 0.97, please accept that (a) we are aiming for 1.0 and trying to read or intentionally misread motivations into that, such as claiming it might be a year away and every checkin requires a new release of third-party code, is somewhere between speaking from no knowledge of the situation and deliberately misrepresenting things and (b) this all came up about a month ago with a similarly "can't make everybody happy resolution" in [1]. All the arguments raised there, both for and against making a release, remain valid. It might sound harsh, but nothing's changed since then. It's very time consuming to go around again on this topic (in fact, it will slow down the next release, and I gather people in this thread want that as soon as possible).
> Finally, for everybody who feels that they really want to write > something in this thread about why there should be a 0.97, please accept > that (a) we are aiming for 1.0 and trying to read or intentionally > misread motivations into that, such as claiming it might be a year away > and every checkin requires a new release of third-party code, is > somewhere between speaking from no knowledge of the situation and > deliberately misrepresenting things and (b) this all came up about a > month ago with a similarly "can't make everybody happy resolution" in > [1]. All the arguments raised there, both for and against making a > release, remain valid. It might sound harsh, but nothing's changed since > then. It's very time consuming to go around again on this topic (in > fact, it will slow down the next release, and I gather people in this > thread want that as soon as possible).
Understandable but that doesn't make me happy. Anyway, Django is not supposed to make me a happy man, just to make my life of software developer a bit less boring. ;)
On Nov 9, 12:41 pm, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> release, remain valid. It might sound harsh, but nothing's changed since > then. It's very time consuming to go around again on this topic (in > fact, it will slow down the next release, and I gather people in this > thread want that as soon as possible).
sorry for bringing this up again, as i said .. i searched the forum but couldn't a satisfieing thread (probably i didn't search long enough)..
i didn't want to offend you by saying that i feel like the release could take another year.. this is just what i think, since i don't know any status.. and looking for information about it gets me the same results as 4 months ago ("when it's done" as i understand it .. maybe i'm misinterpreting .. but not deliberately ;) )
