[Bf-committers] version naming

[Jeroen Bakker]

Hi all,

I suggest to implement any technical change in Blender2.5 as the 
implementation might break upwards compatibility. Eventually my goal was 
not to discuss the implementation, but to say that changing the version 
numbering has some effects that has to be investigated. As there is a 
small possibility that these effects can harm more than we can oversee 
at this moment.

Technical there are always solutions. There is one mentioned already, 
but there is no clarity if that one can be read in older versions of 
Blender.

Jeroen.




Tom M wrote:
> On Sat, Apr 10, 2010 at 12:01 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
>
>   
>> Thanks Jeroen for bringing this aspect of version numbering up.
>> I'm not really interested in discussing this but for the record, agree
>> with your comments above, +1
>>     
>
> Is the versioning number really that incredibly difficult to overcome?
>
> Even if so a major number change for this release still makes sense.
> Even if we don't do it for every significant release.
>
>   
>> One other reason I'd hold back from 3.0x is the api for the first
>> release of 2.5x wont be at all stable for a while.
>> - Catch 22, people wont test until a release and we dont have the
>> resources for really good evaluation of our apis, so a few iterations
>> is normally needed.
>>     
>
> The people holding back are those being told to not use them because
> they aren't stable yet.  However not using them for that reason, it
> sounds like you want to have an unstable API for at least two versions
> after the release.  I think perhaps we should instead lay out a
> testing/feedback plan for our API.  If end users have a defined period
> to give feedback, I suspect that more testing and feedback will
> happen.  If you tell users 'don't test it yet it is unstable' and then
> ask for feedback right at release, then obviously you aren't going to
> get the API tested and will have to do some releases to get feedback.
> How about we decided on some targets for feedback - which APIs are
> ready for feedback? Math and Mesh?  Others?  We can announce at cgtalk
> and blendernation the APIs we want feedback on now, ie what common API
> calls they feel are missing, what things are inconsistent, etc.
>
> I'd suggest we target an API for testing/feedback every two weeks (or
> week even).
>
> LetterRip
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>