[Bf-committers] Changing the release method to have a maximum time

[GSR]

Hi:

>From talk in meeting, it seems releases take a lot from one to next,
so users feel anxious for next things and coders wonder, without
feedback, what is going with their work. Maybe it is time to change
system to a fixed time limit (not minimum), and make sure this way
everyone knows better where things are in the time line. It would mean
that every two months (for example) or less, there would be a
release. This plan should be taken into account for end of this year
or beginning of next, after the 2.40, not good to change methods with
Blenderconf etc ahead.

If the CVS is in unstable status, the release will be labeled AAR
(Adventurous Artists Release, or other similar name... there were more
examples of names in IRC, it would be like DR Developer Release that
you see of libs, compilers, OSes...) and coders would only need to
care about basics things like source compiles and does not crash on
start up (what everyone expects from CVS).

The idea is the files will say something like XYZ but the splash,
header and the packages will say X.YZ-AAR. That will also allow to
keep a reasonable partitioning of .blend compatibility, as every two
months magic number will be changed. The exact moment of the change
should be decided by the code changes in that two month interval,
sometimes it will be a couple of weeks after previous release if
serious changes require it for load and save, others just before
compiling for next release.

There would be no in depth release notes, just a note about were the
current in work docs are, and explaining that bad things can happen,
so no good to use for serious things like paid work. But making clear
everyone is invited to test the parts that seem to work, to make sure
they really do and keep on doing. It would be like CVS builds some
people do, but with official stamp.

Every now and then (lets hope two times per year minimum) there should
be an effort to release a no-AAR Blender, stopping new features and
just focusing in making next timed release to be stable. If that
release has to be AAR again due too many issues uncomplete, then work
should still be kept focused: try to make a new stable release, and if
it can be released before two months, do it then. The intermediate
"oops, it has to be AAR again" will work as reminder to users and
coders to test and fix things, and that the hope is to have stable in
weeks.

BCon would require a bit of redefinition:

BCon 1 will take place after a stable release, so next ideas are put
in the table and work can start.

BCon 2 will be while there is no plan to make stable release yet
(maybe next is AAR, maybe no decission yet) and so coders can work in
new things. AAR releases at this level are pretty fine.

BCon 3 will be set when next is planned to be stable (stable version
V+1). Or in worst case it will be "one more AAR" (still V+1).

BCon 4 will be used if that "one more AAR" has to take place, as
attention call. Or for a short period of time just before a stable
release when all is going fine.

BCon 5 will be when stable (no-AAR) is released.

To sum up, AAR in level 2, "one more AAR" in level 4 and stable in
level 5.

Ideal would be all stable releases :] , but 1 each 2 or 3 seem pretty
reasonable as intermixes one or two fully public tests between
stables. Speaking in time terms it would be one stable each 4-6
months, remembering that if stable can be done just three weeks after
an AAR, it should be done, and start counting the two month limit
since that new release.

It would also mean more splash contests, which could even give extra
interest for users and different styles. When next release ahead
should be stable, people could do two versions, for stable and for
"one more AAR", sharing concepts. And clearly AAR ones could show the
unstability, allowing a bit humoristic images.

What should be clear is that this should encourage constant testing of
releases or even non official CVS buils (by just calling attention to
them indirectly). Remember that the topic or tools used in the
splashes normally make references to what the release has, so artists
will be encouraged to use the previous release to make the splashes,
as well as non official builds.

In conclusion, quicker access to official things for users, and more
testers for coders.

GSR