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

[Constantin Rahn]

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 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