Release Schedules and Feedback on Fixes

[Robert Brenstein]

>Right Robert,
>
>But here also plays next point:
>
>     I could agree if we keep tons of not fixed bugs for years,
>     and push instead forward new features like people complain about RB.
>    
>With each new release of Valentina we have in Mantis practically all fixed
>user reports.
>
>I.e. Bug become into day light only when somebody stick into it.
>
>Bugs have own life and own horoscope :-)
>
>
>--
>Best regards,
>
>Ruslan Zasukhin
>VP Engineering and New Technology
>Paradigma Software, Inc
>

Don't take it so personal :) Nobody said that you are leaving any 
bugs purposefully unattended. On the contrary, you are often praised 
for fixing them overnight. Yes, bugs are a fact of life. In Valentina 
and in our programs. Yes, your support is excellent, far better than 
many other companies. Your continuing development pace also exceeds 
that of many companies. This is good not bad and something to be 
proud of.

But... you are a developer of a tool for other developers and you 
seem to sometimes forget that our programs, particularly products for 
others, have their own life and development cycles. And that is a 
fact that lack of branching forces at least some, if not many, of us 
to get the newest beta only because you fixed some bug along the way 
which affects us. Just think how many times you tell people reporting 
some problems to first fetch the newest available beta and check 
whether the error is there. If release 2.4.x is working for me, I 
should not be forced to upgrade to 2.5.x because of a minor or not so 
minor bug fix.

Imaginable or real, each upgrade skipping a few Valentina releases 
(even betas) can break our programs in subtle ways, as a number of 
people on the list have experienced. This is reality exactly because 
bugs have own life and own horoscope :-) Some of these bugs can 
actually be in our code, only brought out by changes (bug fixes or 
improvements) in Valentina. Also, some bugs may have never made it 
into Mantis for one or the other reason, like lack of a receipe, so 
you had no chance to fix them.

Ruslan, let me remind you that this is not a new complaint, or better 
said a request. I have been around long enough to know that this was 
requested a few times during the active life of V1. In the earlier 
development of V2, branching would slow things down indeed, but V2 is 
now mature enough and feature-complete enough to bring the issue of 
branching and thus continuing direct support of public releases back. 
Yes, it boils down to continued direct support of public releases. We 
are not asking for anything really special. This is an industry 
standard practice, followed by majority commercial software 
developers.

Let me be very explicit with what I mean. If you branch 2.5 now and 
keep fixing its bugs, by the time 2.6 is publicly released, the 
2.5.5, 2.5.9 or whatever release of the 2.5 branch should be really 
stable, as in no known bugs. This means that when 2.6 is officially 
released, we can also branch our products easily: we can continue to 
support version based on 2.5 technology while developing version 
based on 2.6 technology (we could have been doing that all along if 
participating in the beta program). Eventually comes 2.7. Now, if 
there is no compelling reason (like a new feature) for my moving my 
specific product to 2.6 or 2.7, I can keep it with Valentina 2.5 and 
be happy. You may not be happy that I am staying with an older 
version but you should be happy that I am happy and continue using 
Valentina. Sooner or later I switch to the newer version. The 
complaint is really that as things are now, we don't have this luxury 
of settling ourselves with a specific Valentina technology release 
because its support is effectively dropped as soon as you move to 
working on the next release.

Sorry for this being so long but I wanted to be painfully clear.

Robert