[Bf-committers] Avoiding regressions, changes to the release cycle.
blender at dingto.org
Mon Jul 29 15:01:09 CEST 2013
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 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:
>> 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..)
>> 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,
>> 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?
> Bf-committers mailing list
> Bf-committers at blender.org
Blender Developer, Artist and Musician
More information about the Bf-committers