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

[GSR]

Hi,
ton at blender.org (2005-10-11 at 1520.12 +0200):
> Makes all sense to me, apart from the weird AAR name. :)

Well, the reason for AAR name is two fold: creative meaning and
challenge purpose.

Creative cos it shows Blender has its own ways, even for names and
purposes. There would be releases every now and then to be used in all
but the most extreme cases. I have heard of apps doing releases for
developers, but not for artists. Blender would.

Challenge as it throws the gaunlet to all the users that have a bit of
spare time. It means this is about creative people that are going to
explore new land. Enjoy the new features, show what you can do with
them, find the limits.

I want is to see things like "Version 2.37 is OUT !" in topic and
people asking "has anyone figured out how to use <feature>" followed
by a reply "Right now I'm testing <feature>". Not "<name removed>
knows that alpha builds ALWAYS SUCK". Those are real quotes from
IRC. It is about the image created on people's minds.
 
> 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".

Yes, but too tightly associated with "avoid", which is the contrary
desired effect with more releases. I want people to happily jump into
the mud and get dirty "building teapots", not sit down until a teapot
is finished and sent to the shop.

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

Release every two months, maybe even every month, and you get the
quick version increase.
 
> 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.

Are these four points AND or OR or a mix?
 
> 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?

Up to you, my intention was getting people involved, not a version
race. I have already seen some project start pumping version numbers
but I did not seem they got proportionaly better.

GSR