[Bf-committers] Avoiding regressions, changes to the release cycle.

Sergej Reich sergej.reich at googlemail.com
Mon Jul 29 14:56:38 CEST 2013


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 29.07.2013, 14:28 +0200 schrieb Thomas Dinges:
> 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 code cleanup..)
> 
> Suggestion:
> At the beginning of BCon3 (major features are in, we work on final 
> touches and fixes) we take the buildbot resource and communicate that on 
> blender.org, blendernation etc, and ask the community to test the builds.
> I don't think we need to provide special builds for a beta test, as long 
> as people report bugs with our official builds, all is fine
> 
> Then at the beginning/middle of BCon4, we do an RC, and then only fix 
> regressions, then release.
> 
> Best regards,
> Thomas
> 
> Am 29.07.2013 14:06, schrieb Bastien Montagne:
> > 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
> 




More information about the Bf-committers mailing list