Miroslav Penchev wrote:

>
> But will make disappointed many peoples that know very well Firebird.
> I think that this is not good idea and talk for inconsequent way of
> work. That does not talk good for us. How you will explain that leap
> of version numbers when some customer or manager asks you?
> Whatever explanation you give - they will think about you, us and
> Firebird that we a very unserious and mistrustful.

We would look like clowns, certainly.
It looks like we are trying to use commercial tricks from companies whose
income is to sell you the next release. We don't sell the product, so why
use those marketing tricks. Better keep trying to produce a better slogan,
but please an honest slogan. Nothing like promising what you can't fulfill.

Year-related number is like getting back the marketing dept, for not for
promoting FB but for putting release deadlines. If FB2 would follow that
convention, it would be FB2003.

One thing that worries me is that already some competitors have highlighted
an unquestionable fact: the small numbers of active core developers in this
project.

> I think that this is worst idea that I ever see in this mail list. It
> is just unserious to skip version numbers. We pretend to be a serious
> product with serious community - we cannot do such thing. Ok we have a
> small version number, but that is reality. We must make popular
> Firebird, not through big version number. What is the version number
> of Linux??? Or Java VM? Version number is not the problem.

Borland skipped one version of BCB. Borland was looking desperately to
present coherence between their Pascal and C++ offerings.
MS skipped one version of VC. MS can do that. Whatever Gates does, the
market bows.

I think we have a bigger lesson in our minds:

We shouldn't try to put almost any feature in the next version. Never again.
We tried to do that with FB2. It has many things many people wanted and
still there are people that would want to put more. We should define some
key features and put them in a the next major version. Minor features can be
added in minor versions, but they are mostly for improvements to the same
features and bug fixing.
When the next chunk of key features (few but important) is agreed, develop
and bump the major version. This is a consistent and serious way to raise
the numbers. Release often, work in shorter cycles. I'm not saying "put
deadlines" but "weight the number of core devs against the demands and
decide on important features doable in a reasonable timeframe for the next
major version".

C.