[Bf-committers] RFC: "Continuous integration" branch?

[Sergey Sharybin]

Hi,

That's true that real testing starts after the release. But it doesn't we
shouldn't make it so master is as well tested as we possible can do it.

As for the rest of suggestion -- we already had that in more early 2.5x
days. That approach has it's own strong and weak sides. Strong side you
already mentioned -- all the releases gets some really awesome major
feature. But on the other hand, it makes it so you need to wait much longer
to get some bug fixed. Even for some smaller improvements you'll need to
wait much longer than it could be.

For such stuff it's much better to release more often even if it's not so
much new major features/improvements.

In any case, thanks for feedback but this kind of discussion does not
really belong to this thread.

On Fri, Mar 6, 2015 at 6:57 PM, David Fenner <d4vidfenner at gmail.com> wrote:

> Truth be told, release candidates aren't very well tested anyway. It's when
> a true release comes when true testing begins. I say it as an artist
> myself.
>
> My personal opinion on this matter is a little more unorthodox, I think
> there simple shouldn't be a "Bcon" and releases every 3 months. I'm very
> serious. This only makes blender development too sparse and out of focus on
> the important things. Releases should come when the goals are met, period.
> Just like Krita does. The big discussion should be about what will this
> goals be, will it be despgraph refactor, hair sim, cloth speed, and some
> other things. If these things are unfinished, then "in the middle"
> releseases just get developers out of focus. Nobody wants a half made tool
> that rushes into a release, or development time wasted in a release that
> doesn't have the tool at all. What is the point of fixing so many bugs when
> there are 20 half baked projects in the way that will come with a ton of
> bugs very soon anyway? Why not make really important releases?  We don't
> care if we wait for eight months for a real release. Then I'd be truly
> interested in testing release candidates, but honestly, if nobody tests
> them right now, is for a reason, and this is "why should I test it if
> another one will come in a very short time anyway? " We can talk about
> community morals here, about being really active and not only ripping of
> the benefits and bla bla bla but in truth, really effective things occur
> when we see things like they really are, not based on ideals.
>
> The fact that this discussion even started shows that something needs to be
> done here, and instead of making separate branches, that as sergey said,
> most people will stick to the development one, I propose simple extending
> the release cycle indefinetely, until clear, big and small goals are met,
> with a cap of course, lets say nine months or a year.


-- 
With best regards, Sergey Sharybin