Original-Nachricht
Datum: Sat, 19 Mar 2011 13:34:29 -0500
Von: Reuben Martin reube...@gmail.com
An: bf-blender developers bf-committers@blender.org
Betreff: Re: [Bf-committers] Roadmap for 2.5x - 2.6x - beyond
I don't know if this has already been discussed or not, but has
This is great.
+1 for Brecht's 8-week release cycle.
My only concern is whether some users might get confused about the release
versions. I think that instead of having 2.58 as the last release, we should
skip to 2.60, and make it the base release for the 2.6x series. This would
make sense (I
Am 13.03.2011 15:52, schrieb Brecht Van Lommel:
Hi,
[...]
There's this dynamic which I think we should try to break: unstable
features push back release dates, then after a while, core developers
in other areas get impatient and add another unstable feature, which
agains pushes things back
Big -1 for this,
seriously let's not change the naming again!
Ton and others decided on naming it 2.57 and 2.58 (Ton sent a mail with
this in January to the ML). Let's stick to that!
This is the n'th discussion about it on this list, and it starts to get
annoying. ;-)
Thomas
Am 14.03.2011
I'm not a coder, but I guess one issue is to determine weather a
branch is stable or not, and to know if it have been properly tested.
Why don't do this in a more systematic, 'official' way than before:
When a branch is getting near completion:
1. Set up a dedicated bug tracker for the branch,
We've been in some kind of freeze long enough now. Let's have fun
for a while, and then try to fix it all up again :)
-Ton-
Those words are music for my ears :)
Congratulations!!!
Cheers
___
Bf-committers mailing list
Bf-committers@blender.org
Sorry.
I had not realized that this was already set until today. I had figured we
would be releasing 2.59 and then 2.60 and then working on new stuff, not
finishing with 2.58. If I had known that I would have started protesting
earlier. If we want to end with 2.58, then that's fine with me, I was
+1 to brecht's proposal, big +1 to shorter fixed release cycles.
-1 for discussions on details of point releases, just go with Ton on
this one and focus on real issues :)
On Sun, Mar 13, 2011 at 3:08 PM, Ton Roosendaal t...@blender.org wrote:
Hi Brecht,
I strongly believe we should switch to
Hi.
Will 2.57 have a stable API?
Yes.
But depends on definition of stable too. Is a matter of documenting
it well. Most of it can be called stable and frozen, some parts might
need bug fixes, and some parts are in WIP or unfinished.
-Ton-
Hi,
I think we should make major modifications to the release cycle, to
avoid problems that we've been having with 2.5 and also releases
before that. In my opinion a migration schedule for new features as we
have done before does not work, because it's unpredictable when
developers will be
Hi Brecht,
I strongly believe we should switch to short, fixed release cycles,
and be much more strict in only accepting functionality in trunk that
is reviewed and can be stabilized in a short time.
Fully agree! :)
-Ton-
Double thumbs up from my end also.
There's a lot to be said about stricter discipline for commits to trunk.
Martin
--- On Sun, 3/13/11, Ton Roosendaal t...@blender.org wrote:
From: Ton Roosendaal t...@blender.org
Subject: Re: [Bf-committers] Roadmap for 2.5x - 2.6x - beyond
To: bf-blender
+1 Here, sounds very reasonable!
On 03/13/2011 03:52 PM, Brecht Van Lommel wrote:
Hi,
I think we should make major modifications to the release cycle, to
avoid problems that we've been having with 2.5 and also releases
before that. In my opinion a migration schedule for new features as we
Hey,
I completely agree with that and be happy that you bring it up now. :)
This 8 weeks release schedule sounds good and doable.
Our main problem was never the amount of new features, it was good
testing and quality. Hopefully this will improve with such a new system.
Very strong +1
Am
14 matches
Mail list logo
