[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