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

[Brecht Van Lommel]

Hi,

On Mon, Jul 29, 2013 at 1:43 PM, Campbell Barton <ideasman42 at 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 build, then making many changes afterwards that aren't properly
> tested.

Agreed.

I think that we should have a longer freeze period for the release,
with only bug fixes that are reviewed by other developers and where
some time has been spent re-testing that area of Blender. 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 released after
e.g. 2 weeks or longer even.

So that would give a longer release cycle with a longer bug fixing
period, but we'd still be making a release every 2 months.

> Some guidelines...
> - Simple fixes such as NULL checks, array index range checks, obvious
> memory leaks... etc, are fine.

I don't really agree with this, no matter how simple it can still
break things in unexpected ways. To me the criterion to allow a bugfix
should not be if it's simple, but if it's important.

> Other things to look into (which I'm not covering)...
>
> - We should really investigate automated testing in areas shown to
> have caused problems in previous releases (big topic).
>
> - Since we can't completely avoid bug-fix releases, we could try to
> make the process less onerous, minor releases shouldn't be difficult,
> if they are, we could look into automating this more too, or sharing
> tasks with more devs.

Agreed here, both of these could be worked on. Ideally the buildbot
could give us exact releases, we could even have it build from the
latest release tag. Only the OS X build really differs here because of
the custom gcc setup I think.

Brecht.