Em 11/2/2014 16:49, Dmitry Yemanov escreveu:

> 11.02.2014 22:20, Alexandre Benson Smith wrote:
>
>> That's the point... we could have minor versions with short release cycle.
> We did what could be done, see v2.1 and v2.5. They appeared exactly
> because the codebase was not ready for v3-promised features and nobody
> wanted to wait 5+ years between releases. It's no longer the case, however.

Yes, I know.. I was just pointing what initially was rised as shorter
release cycle, where Dmitry Sibiryakov tells the we have a daily release
cycle with snapshots.

>> So, if during this alpha stage the development team find some really
>> serious problem with SMP on 3.0, we should wait for 4 ou 5 years until
>> it's fixed ? Or do you think that a re-schedule (realease a 2.6 or
>> anything you name it) with bug fixes, security fixes, new features, but
>> using the old SMP architecture, is not an option ?
> It is surely an option. However, with no serious problems re. SMP but
> with huge efforts required for debugging/testing it, how could v2.6 be
> possible? All the non-SMP fixes / features also require a lot of
> testing/bugfixing. We either develop one thing or another, but not both.

Agreed

>
>> I think we live on a dynamic world that anything could and should be
>> changed if it will be better.
> As long as it's practically doable.

Of course...

>> For me will be much more important to free Firebird from the 27 chars
>> restriction on object names, or a new wire protocol, than to have a new
>> SMP architecture. If one say that he needs 5 years to implement a new
>> SMP architecture, but 6 months to release a new version without the 27
>> char limit you could bet that I would choose the 6 months version.
> The limit is 31 chars in v2.5. I know many users would like to extend
> it, although the Oracle example shows us that it's not really that
> important as people tend to think.

I always forget how long it could be, but you get the point... Well I
(and everyone else) live with that limit today and have lived for 10+
years, but I think it hurts sometimes... I just pointed this particular
issue to say that I (and I am not saying everyone) would prefer a longer
object name and live with the actual SMP architectures.

>> And, in the background the longer tasks could be developed without
>> restricting the release of the new (not so major) versions.
> In the background? Do we have a dozen of developers with free hands? ;-)

No, I think you have a dozen hands at all... Dmitry I really understand
the lack of work force, and I really apreciate all the work done so far,
Firebird is the only database I use in my products (there is only one
project using Oracle, but I will not count it).

My point is just that there is other paths for a shorter release
cycle... And that's it... And don't said any time that the firebird
developers did less than it could be done...

>> As I said before, FB 2.1 (yes I don't even use 2.5 in production) fits
>> me very well, but if I could put my hands on other minor features faster
>> I would get some benefits from it.
> I have nothing against the idea in general, I just want you to look at
> the issue from another side. v3 is the next major release, it was
> already delayed twice. v2.6 or whatever means delaying it once more, at
> least for one year. If longer, you'll suggest v2.7... and some day I
> will get tired of promising SMP to another part of users who is waiting
> it since 2005.

I know it...I prefer a stable release that is instaled on my costumers
that don't need to be upgrade every 6 months (look I did not upgraded to
2.5 in production because the new features available are not critical
for me), but, I think that the release time could be shorter even if
each new release contains fewer features. And I think you already got
this point.

>
> Dmitry

Anyway, to be clear, I really like Firebird, I have no single issue that
makes me wish to use another database, and I really like the job all of
you have done with so few available hands. My comments have just one
goal, try to put my thoughts on the table with the desire to help make
it even better.

see you !