I apologise again, but I don't really agree with any of that:
On 9/16/05, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 9/16/05, Ben Fowler <ben.the.mole@...400...> wrote:
rather than new features. Ideally we need to know whether the user community would vote for quality and bug fixes or new features ...
This is a "black or white" approach that won't work. Users never want either bug fixes or new features. They want both (and NOW :)).
Speaking personally, a lot of the software that I use evolved their necessary feature set around 10 years ago. I would always vote for quality and bug fixes, and in some cases actual removal of features. Whilst this sounds heretical, this is not a rare and not even an especially unusual point of view.
Principally, _any_ pre-1.0 release should be considered as buggy.
Yes, but we have end users using Inkscape for their regular work. They do not want regressions, and (to repeat) are entitled to have their views concerning features listened to.
Bear in mind that good software is made from bug reports, and we will only get bug reports if (to pick up a few necessary points) the software is overall reliable enough to trust, developers are responsive, total bug counts are low ...
I suggest the following scheme we seem to follow anyway:
0.43 - both bugfixes for 0.42 and new features 0.43.x - bugfix releases 0.44 - both bugfixes for 0.43 and new features 0.44.x - bugfix releases 0.45 - both bugfixes for 0.44 and new features
In the first place, this is the even/odd scheme without using the concept of the number '2'. You could also switch to NN-preview followed by NN (back to alpha, beta release candidate), or add a patch number (I think that perl and vim do that). These schemes either involve more work for little benefit or are appropriate for mature products. (You don't expect showstoppers in perl or in vim). Finally, they have the fearful circular problem that if we release 0.43.0 saying that .0 means it is not good enough for use, then we will not get the people we want to use it (those who will give good bug reports and feedback) to download it and try it. (Did you read the 0.42 Slashdot article: There is a lot of ignorance and a certain amount of hostility out there?).
I think that everything that we release should be as good as we can make it, and if something is forward looking (untested and could have showstopping bugs) then it should be labelled as -HEAD dr or possibly alpha.
Most significantly, you assume (in this schema) that it is sufficient for version 0.43 to fix bugs uncovered in version 0.42; to wit that we have a zero defect policy in place.
I may be wrong, or it may not be my place to say, but I think that we should cater for bugs going back months.
This is why I suggest that from a developer's point of view, we either need to be able to slipstream older bug fixes (my thaw policy as outlined above) or have protected releases when we only do bug fixes. Obviously the latter might be ruled out if you felt it was anathema, unnecessary pre-0.1 or not possible owing to the large number of enhancements going through.
Ben