A final post-0.91 release?
James Bennett
to roll up a bunch of bugfixes against pre-m-r Django (e.g., 0.91) and
do a '0.92' or some other form of final release for the old-style
Django.
Since I just lost about an hour of my life to dealing with a problem
in pre-m-r Django which had a fix in Trac that was never applied
(ticket #1113 for those who are interested), I'm suddenly intensely
curious about the possibility of this happening.
Would it be prohibitively difficult for some of us to scour Trac
sometime for known bugs and patches in which came between 0.91 and the
pre-magic-removal tag, and work on rollin a release out of that?
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
Deryck Hodge
>
> Back when the magic-removal branch was still going, there were plans
> to roll up a bunch of bugfixes against pre-m-r Django (e.g., 0.91) and
> do a '0.92' or some other form of final release for the old-style
> Django.
>
> Since I just lost about an hour of my life to dealing with a problem
> in pre-m-r Django which had a fix in Trac that was never applied
> (ticket #1113 for those who are interested), I'm suddenly intensely
> curious about the possibility of this happening.
>
> Would it be prohibitively difficult for some of us to scour Trac
> sometime for known bugs and patches in which came between 0.91 and the
> pre-magic-removal tag, and work on rollin a release out of that?
>
I know at NDN we're going to be pre-mr for the foreseeable future (and
probably all of Scripps, too). Even if not an actual release, just
compiling a set of patches known to be useful for those on pre-mr
releases would be nice.
Whatever works best, though. I don't mind helping if something like
this is feasible.
Cheers,
deryck
--
Deryck Hodge http://www.devurandom.org/
Web Developer, Naples News http://www.naplesnews.com/
Samba Team http://www.samba.org/
Jeremy Dunck
> I know at NDN we're going to be pre-mr for the foreseeable future (and
> probably all of Scripps, too). Even if not an actual release, just
> compiling a set of patches known to be useful for those on pre-mr
> releases would be nice.
+1 from Pegasus News-land.
Adrian Holovaty
> in pre-m-r Django which had a fix in Trac that was never applied
> (ticket #1113 for those who are interested), I'm suddenly intensely
> curious about the possibility of this happening.
>
> Would it be prohibitively difficult for some of us to scour Trac
> sometime for known bugs and patches in which came between 0.91 and the
> pre-magic-removal tag, and work on rollin a release out of that?
As long as it's strictly bug fixes, and no feature additions, that
sounds fine by me. The reason I say "no feature additions" is that it
wouldn't be in our best interest to have another competing branch, as
we did with magic-removal vs. 0.91 a while back.
Granted, I think people overwhelmingly agree that there's really no
reason to continue using pre-magic-removal Django except for legacy
reasons, so there's not much incentive to add feature additions to
this branch in the first place -- but I figured it was worth pointing
out.
James, assuming you agree with these goals, are you volunteering to
maintain the branch? :-)
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Deryck Hodge
> As long as it's strictly bug fixes, and no feature additions, that
> sounds fine by me. The reason I say "no feature additions" is that it
> wouldn't be in our best interest to have another competing branch, as
> we did with magic-removal vs. 0.91 a while back.
>
> Granted, I think people overwhelmingly agree that there's really no
> reason to continue using pre-magic-removal Django except for legacy
> reasons, so there's not much incentive to add feature additions to
> this branch in the first place -- but I figured it was worth pointing
> out.
I'd much rather be on current SVN myself. :-) My interest is just in
killing bugs.
James Bennett
> sounds fine by me. The reason I say "no feature additions" is that it
> wouldn't be in our best interest to have another competing branch, as
> we did with magic-removal vs. 0.91 a while back.
Of course. The goal would simply be to provide bugfixes for people who
are still supporting legacy installations.
> James, assuming you agree with these goals, are you volunteering to
> maintain the branch? :-)
If that's what it takes, then yeah :)
Adrian Holovaty
> > James, assuming you agree with these goals, are you volunteering to
> > maintain the branch? :-)
>
> If that's what it takes, then yeah :)
OK, I've set up a 0.91-bugfixes branch and given you commit access. Have at it!
Jeremy Dunck
> OK, I've set up a 0.91-bugfixes branch and given you commit access. Have at it!
>
It looks like neither branch is particularly lively just now. I'm
trying to decide whether to catch up to 0.90 or 0.91 from r1338. Of
course 0.90 is easier to get to, but if more developers are coding on
0.91, then maybe I'll try to catch that.
Thoughts?
James Bennett
> It looks like neither branch is particularly lively just now. I'm
> trying to decide whether to catch up to 0.90 or 0.91 from r1338. Of
> course 0.90 is easier to get to, but if more developers are coding on
> 0.91, then maybe I'll try to catch that.
Well, if you can point me at bugs that need to be fixed in either one
I'll happily get on it :)
So far I've applied security patches, and fixed a few of the known
bugs from Trac and merged in a few fixes from some of our internal
stuff.
Jeremy Dunck
>
> On 9/19/06, Jeremy Dunck <jdu...@gmail.com> wrote:
> > Of
> > course 0.90 is easier to get to, but if more developers are coding on
> > 0.91, then maybe I'll try to catch that.
>
> Well, if you can point me at bugs that need to be fixed in either one
> I'll happily get on it :)
>
We're now on 0.91 (but not -bugfixes yet).
We just ran into http://code.djangoproject.com/ticket/2745 , which has
not been applied to 0.91-bugfixes yet.
Thanks!