Fate of 0.91 projects
David S.
patches that have been made to trunk in the meantime. Since magic-removal will
be too backwards-incompatible to use in this project, should I be applying
important patches (like http://code.djangoproject.com/ticket/1442), expect a
0.91.1, or grab the last pre-magic-removal version from svn when that exists?
Thanks for the advice.
Peace, David S.
Michael Radziej
I can still see important fixes for trunk in the svn, so you're probably
well off using the svn trunk.
Michael
Adrian Holovaty
Depending on demand, we may release a final pre-magic-removal release
of Django -- maybe 0.91.1 or something. Or maybe it'll be 0.92 and
magic-removal will be 0.95, to signify it's a big leap. Thoughts?
For your immediate concern, I'd urge you to use Django's trunk.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
David S.
and should have it's own label before the significant changes the M-R
development will introduce.
With more thanks for all the hard work,
David S.
yi huang
I think magic-removal is stable enough to release. and i think everyone should turn to 0.92(pre-magic-removal).
http://codeplayer.blogbus.com/
Jeroen Ruigrok van der Werven
> of Django -- maybe 0.91.1 or something. Or maybe it'll be 0.92 and
> magic-removal will be 0.95, to signify it's a big leap. Thoughts?
The one thing I am slightly concerned about is the fact that the MR
branch is lingering and lingering and diverging beyond simply the
'magic removal' goal that was set at first.
How many more changes are expected before a new release or in other
words: what's the schedule? :)
--
Jeroen Ruigrok van der Werven
Adrian Holovaty
> The one thing I am slightly concerned about is the fact that the MR
> branch is lingering and lingering and diverging beyond simply the
> 'magic removal' goal that was set at first.
>
> How many more changes are expected before a new release or in other
> words: what's the schedule? :)
Look for an announcement on this soon...It's about time to get a
schedule set up.
Kenneth Gonsalves
> Depending on demand, we may release a final pre-magic-removal
> release of Django -- maybe 0.91.1 or something. Or maybe it'll be
> 0.92 and magic-removal will be 0.95, to signify it's a big leap.
> Thoughts?
next release *must* be magic removal - no point doing any interim
releases - one drastic piece of surgery and then 1.0 ... interim
releases would just prolong the agony
--
regards
kg
http://www.livejournal.com/users/lawgon
tally ho! http://avsap.org.in
ಇಂಡ್ಲಿನಕ್ಸ வாழ்க!
Jeroen Ruigrok van der Werven
> next release *must* be magic removal - no point doing any interim
> releases - one drastic piece of surgery and then 1.0 ... interim
> releases would just prolong the agony
I have to agree with Kenneth here.
Any day you prolong the non-MR use is going to come back later for
people who need to convert from one system to another.
Better to bite the bullet and get this over with.
The better question might be: is the current magic removal branch that
what you intend for a 1.0 version?
--
David S.
> On 4/14/06, Kenneth Gonsalves <lawgon <at> thenilgiris.com> wrote:
> > next release *must* be magic removal - no point doing any interim
...
> Better to bite the bullet and get this over with.
...
I was thinking simultaneous release. Really just for the sake of a label for
the pre-magic removal stuff. This is not about "biting the bullet" or any of
that. I am talking about projects that are complete and for which it would be
mighty convenient to have the last and best code to run on. When it comes time
for rev 2, we'll be happy to move to 1.x or whatever Django is at.
Of course, it can always be fetched from SVN, it just feels better to have a
nice EGG for your disaster recovery stack.
Leeuw van der, Tim
on trunk. Perhaps patches applied for concurrency/threading issues and
memory leaks -- that would be great for stability, esp. on windows.
Then instantly switch trunk to m-r, and if m-r is good enough, make a
release of it.
Cheers,
--Tim
Bill de hÓra
> On Thursday 13 Apr 2006 6:54 pm, Adrian Holovaty wrote:
>> Depending on demand, we may release a final pre-magic-removal
>> release of Django -- maybe 0.91.1 or something. Or maybe it'll be
>> 0.92 and magic-removal will be 0.95, to signify it's a big leap.
>> Thoughts?
I think your next release should be an alpha based on magic-removal not
an upgrade of .92. Cut your losses. Fwiw, as a bystander, magic-removal
has been too long on the branch and looking at the commit history it
seems to be your true development trunk (ie there's a lot more than
magic removal going on). It needs to get merged back or killed.
Simulataneous releases will confuse people and enhance any perception
that Django is unstable not ready for production work. Parallel branch
management has really hurt the Zope community for example; there are
lots of other examples out there.
cheers
Bill
Jeroen Ruigrok van der Werven
> I fully agree with this: a 0.92 made of trunk, with all fixes collected
> on trunk. Perhaps patches applied for concurrency/threading issues and
> memory leaks -- that would be great for stability, esp. on windows.
> Then instantly switch trunk to m-r, and if m-r is good enough, make a
> release of it.
I can definitely live with this course of action and would throw my
vote in for this.
--
Jeroen Ruigrok van der Werven
> I think your next release should be an alpha based on magic-removal not
> an upgrade of .92. Cut your losses.
There has been some commits to the trunk and given how some hosting
parties will not install non-released versions I think it might be
fair for those people depending on that to release a 0.92 or something
like that prior to cut everything in MR over to trunk.
> Fwiw, as a bystander, magic-removal
> has been too long on the branch and looking at the commit history it
> seems to be your true development trunk (ie there's a lot more than
> magic removal going on). It needs to get merged back or killed.
Branches are indeed meant for testing and such without disrupting the
main development line. But given how the main development line will be
the MR code it needs to be moved back to trunk.
> Simulataneous releases will confuse people and enhance any perception
> that Django is unstable not ready for production work. Parallel branch
> management has really hurt the Zope community for example; there are
> lots of other examples out there.
I have to agree to that sentiment too though. The less confusion the better.
James Bennett
> that Django is unstable not ready for production work. Parallel branch
> management has really hurt the Zope community for example; there are
> lots of other examples out there.
+1.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
aaloy
>
> On 4/14/06, Bill de hÓra <bi...@dehora.net> wrote:
> > Simulataneous releases will confuse people and enhance any perception
> > that Django is unstable not ready for production work. Parallel branch
> > management has really hurt the Zope community for example; there are
> > lots of other examples out there.
>
> +1.
put the actual trunk as a branch just to mantain security issues with
that affect the 0.91 version.
I'll prefer to deal with an alpha M-R version knowing that this is the
main trunk than inverting my effort in developing applications that I
positivelly know I should remake in order to adapt to the near future
development.
The M-R should also involve a documentation and examples re-write, as
the quality of the documentation is one of the most important factors
that diferentiates Django.
--
Antoni Aloy López
Binissalem - Mallorca
Soci de Bulma