[Bf-committers] version naming

[Tom M]

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