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

[Ton Roosendaal]

Hi,

Makes all sense to me, apart from the weird AAR name. :)

The Bcon schedule hasn't been extremely strict followed until now, but  
I still like the switch from '2' (new projects worked on) to '3' (specs  
finished for release). Test releases can be done during both periods,  
with cumulated stability for those projects that were finished, other  
projects can be unfinished still, so hard to give this stability a real  
'number' or value. All test releases during that period can carry a  
"Beta" or "Pre" tag, which is more commonly known than "AAR".

During '4' we can make releases called "RC" (release candidates), and  
these should be based on increased stability all over.

The main problem is Blenders internal version code, which is just a 3  
byte code (string) in files, and a short in the code. With our projects  
tending to become more complex, and releases done less often, we might  
consider to go for bigger jumps in our version naming.

Without changing our current system (backward/upward you know) too  
much, I can think of the following;

- add in the code an optional string tag, to be appended to the version  
itself ("-Pre" or "-Beta" or "-RC", or "-update". This will only show  
in UI.
- add an additional sub-version code in Blender, which is invisble and  
only used by the file patching do_versions() in readfile.c
- increase for each official test build (at least once a 2 month) the  
version number.
- Move for official stable releases to units of 10. (Meaning, next  
official stable release will be 2.50, then 2.60, etc). This allows 10  
official testbuilds to be done inbetween, which is more than  
sufficient.

BTW; Blender has moved from 1.00 to 2.00 in about 4 years. All  
development from 2.00 to 2.40 is already extremely impressive, so we  
could consider to move on to 3.0 as well, for example targeted next  
year summer somewhere?

-Ton-

On 9 Oct, 2005, at 21:43, GSR wrote:

> 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
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org