Hi Cam,
Yep we gotta move on. Was suffering jetlag and few days heatwave in Amsterdam :)
Reading all comments, I think there's consensis to:
- Do the usual test build in BCon4 period, just a snapshot of trunk
- Make a real RC, which is the tagged release branch (with splash, release nr,
etc)
-
Sounds like a very good plan, especially to do a real RC, also with
splash and version bump already. That confused people in the pas as well.
Thanks!
Am 02.08.2013 18:14, schrieb Ton Roosendaal:
Hi Cam,
Yep we gotta move on. Was suffering jetlag and few days heatwave in Amsterdam
:)
On Sat, Aug 3, 2013 at 2:14 AM, Ton Roosendaal t...@blender.org wrote:
Hi Cam,
Yep we gotta move on. Was suffering jetlag and few days heatwave in Amsterdam
:)
Reading all comments, I think there's consensis to:
- Do the usual test build in BCon4 period, just a snapshot of trunk
- Make a
Any conclusion to this thread?
Ton, you responded to a separate issue which Brecht raised (which is a
valid discussion), but I'm concerned that disagreement on larger
changes to the release-cycle get in the way, the topic gets dropped -
then we don't make smaller (IMHO common sense) changes like
Brecht Van Lommel wrote
If we can somehow turn the release into RC and 2.68a into 2.68 then I
think that is a step forward.
This user is already doing that. Skipping the 2.68 release and waiting for
the 2.68a release on any systems where I need reliability.
--
View this message in context:
Replying to most of the replies to this thread...
@Jürgen Herrmann,
re: 3 month releases,
We can of course change release schedule however we want, my point was
mainly that I think it wont make blender more stable on its own, if we
want to change release schedule for other reasons then
Regrading the original mail in this thread, I completely agree with
being more strict in the week before release. That's a rule that is
supposed to be there already but we don't follow it well, so we can
agree as core developers to enforce that better for the next release.
The only thing I fear is
Hi Brecht and Campbell.
I can't follow this renaming proposal really...
For as long we work with communities and volunteers out there, we should assume
them to be preferring to use the latest svn checkout any time. For that
reason moving release candidates to branches will just mean it gets
Hi Ton,
To me the problem seems to be exactly that people are focusing on
stabilizing right up until the release. We get 100 bugfixes in those
last weeks, and some of those fixes will inevitably break something
else. If we want things to be tested well we need to freeze the code
for a while
On Tue, Jul 30, 2013 at 7:43 AM, Ton Roosendaal t...@blender.org wrote:
That's why we added the 'BCon' cycle, where the last 2 cycles were meant
for everyone to stop coding new stuff for 3+ weeks, and focus on
stabilizing and fixing and testing of trunk (and *not* work on branches).
... or
Last meeting we discussed changes to release because of bad
regressions in recent releases.
It was suggested that we move to 3 month release cycles.
I believe this wont help, since its not really solving the problem,
consider that we had 1 week extra to fix bugs for 2.68 (and we _did_
fix a lot
Hi,
I think 3 months would be great to introduce an additional beta build right
before the RC.
This could help to find regressions before we build a RC.
/Jürgen
Am 29.07.2013 um 13:43 schrieb Campbell Barton ideasma...@gmail.com:
Last meeting we discussed changes to release because of bad
I would consider daily bot-built blender’s as “Beta”… After all, we
never (intentionally) break /trunk, so those builds should always be
usable, even though not strictly tested. Isn’t it the definition of
“beta” release?
Bastien
On 29/07/2013 13:56, Jürgen Herrmann wrote:
Hi,
I think 3
Hi Campbell,
thanks for bringing this topic up here on the mailing list, answers inline.
Am 29.07.2013 13:43, schrieb Campbell Barton:
Last meeting we discussed changes to release because of bad
regressions in recent releases.
It was suggested that we move to 3 month release cycles.
I
Hi Bastien,
IMHO the build bot builds are more of nightly development builds. Most users
don't even look at them.
A real beta could be built at the beginning of BCON4 and advertised on the
website so users are aware if that.
Then we do a RC after regressions are fixed and release the final
Hi,
We should communicate the Buildbot resource better (too many people
still use graphicall with experimental patches blah for testing).
But if we are really strict with terms, then we are only in beta,
starting with BCon3. I would consider BCon 1 and 2 as Alpha (many new
features, lots of
Hi,
there should be no changes after an RC. If there are show stoppers in
the RC and/or last minute changes, than we need an additional RC. RC1,
RC2, ... RCn.
The last RC should be identical to the final release, differs only in
the version tag.
Conz
Am 29.07.2013 14:28, schrieb Thomas
I think the biggest problem with testing is that only a few users
actually test the daily/RC builds. Having a longer testing period would
help here, but I doubt it would make a dramatic difference.
Most bugs are found after release.
Don't think you can do anything about that.
Am Montag, den
I just checked,
since the 2.6x series (starting with 2.60) we only had 2 releases which
survived without an update: 2.61 and 2.62.
Am 29.07.2013 14:56, schrieb Sergej Reich:
I think the biggest problem with testing is that only a few users
actually test the daily/RC builds. Having a longer
Hi,
I have a feeling that often the current BCon level is not on everyone's
minds when they commit. I'm not sure if this is possible, but is there any
way we could have an SVN hook that reports the current BCon level and
during BCon 4 asks for confirmation that it's either a very simple or
Hi,
On Mon, Jul 29, 2013 at 1:43 PM, Campbell Barton ideasma...@gmail.com wrote:
I think there are 2 problems with how we are doing releases currently.
- We're making risky changes/fixes too close to the release date.
- RC's are not really 'release-candidates', we are asking users to
test a
On Mon, Jul 29, 2013 at 3:43 AM, Campbell Barton ideasma...@gmail.com wrote:
To be clear there were 3 regressions that I'd consider show stoppers.
- Crash deleting a sequence strip r58374
- Removing vertex colors crashes r58436
- Painting Undo Enable Face paint Crash r58509
Since all 3 of
On Tue, Jul 30, 2013 at 4:41 AM, Tom M letter...@gmail.com wrote:
On Mon, Jul 29, 2013 at 3:43 AM, Campbell Barton ideasma...@gmail.com wrote:
To be clear there were 3 regressions that I'd consider show stoppers.
- Crash deleting a sequence strip r58374
- Removing vertex colors crashes r58436
On Mon, Jul 29, 2013 at 7:26 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
I don't think we need to freeze trunk for that however, we could just tag
the
new release and open up trunk for development again. Then any critical
fixes found can be ported to the tag which would be
24 matches
Mail list logo
