Release Schedules and Feedback on Fixes

[Robert Brenstein]

>  > 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.
>
>But if 2.6 is expected to be in 15-20 days only?

Well, the version numbers I used were just examples. If you plan next 
public release within a month, then it may make little sense to 
branch now but wait until it is out. On the other hand, if you 
already use something like Subversion, you may do internal branch 
just in case. All it takes is just a few cvs commands. Whether you 
use or not, is a separate story.

>I can understand what you say if 2.6 could take 3-6 months.
>This is what is going to be for 3.0.
>
>They yes 100% agree:
>     * we ship 2.6 as last 2.x release with major fixes.
>     * we branch it
>         - and start development SIGNIFCANT new features.
>         - may be we will need yet ship 2.6.x during this months.
>
>With such plan I agree. Do you ?

Fine. In branching, the main development branch has no version per se 
but is called HEAD. So whether you will head (pun intended) to 3.0 or 
2.7, makes no difference at this stage. It matters only that you 
formally branch 2.6, so it gets life on its own (even if it is only a 
life support system :-)

Look for example at http://docs.moodle.org/en/images_en/8/8a/Cvstree.png

This picture depicts the branching tree for Moodle, another product 
that I am deeply involved with (and which as I mentioned earlier 
could be a new selling field for valentina -- Microsoft lately 
sponsored them to support MSSQL and they used the money to develop a 
generic database interface).

The picture illustrates nicely the concepts of branching. Substitute 
"Moodle_1x" with "Valentina_2x" and you could have your branch tree. 
The WIDGET branch below the trunk, by the way, is a private branch to 
develop a major feature independent from the main development trunk, 
and which was eventually merged into it.

>  > 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.
>
>And here main trap:
>
>     what if YOU find new bug in 2.5 build AFTER 2.7 is released?
>
>     you will ask us make 2.5.1?
>     I believe any company do not do this.
>     they fix bug in 2.7.1 and say you - upgrade to 2.7.1, right?

Well, it all depends. If you know that there are many users still 
relying on this branch and are affected by this bug, it may be worth 
your trouble to fix it and release it as a plus release (an interim 
release, essentially a beta on fixes applied to a branch) or a bigfix 
release if the fixes are verified. If it is a minor problem and 
affects few, you may let it go unfixed in 2.5 branch but fix in the 
2.6 branch and the head.

In general, you would formally commit your self to maintain only the 
last public branch. Of course, if your major (public) releases are 
only 3 months apart, users may expect you to maintain the last two 
branches.

It may sound scary, but with cvs and its features to propagate code 
changes (bug fixes) between branches this is actually little extra 
work for your team. The only thing that you need to maintain 
(actually just consciously keep) is the compiler setup that is used 
to produce each branch that is actively supported.

>  > 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.
>
>About dropped ... Well, can I ask Microsoft fix a bug in Visual 2003 C++ ?
>Today exists Visual 2005. I think they never will do that. Am I right?

The BIG guys seem to have their own ways of fixing bugs. I mean how 
they decide what to fix and when. But if I am running Windows 98 
compouter, I can still ask it to fetch the system updates and in fact 
until recently I was still finding new security patches. Same is with 
OS X. Regardless which major branch I have, i can still fetch all 
updates that were available to the branch I am running, and 10.3 is 
still getting security updates once a while even though 10.4 has been 
out for quite a while.

But an operating systems may be not an optimal example. Go to 
www.filemaker.com to their support pages and to downloads. The latest 
version of Filemaker I bought was 4.1. I can still fetch the 4.1v3 to 
update my 4.1 version. And so it is for any other major branch of 
Filemaker within each product. The same was possible with CodeWarrior 
while Metrowerks was still in business. I remember downloading CW8 
updates while already running CWP3.

Yes, branching is not only about the actual bug fixing but as 
important is the long-term availability of the updates in each branch 
even if it is no longer actively supported.

>I think I understand what you say. And I think I remember the BIG change in
>1.x when we have introduce record locks. This have break existed code. You
>have point me that this is bad that new incremental update do such big
>changes in API/behavior.
>
>My understand is that on that moment we was need say: this is a 2.0 version
>- major release. Instead we still MANY YEARS did slow 1.x incrementing.

Yes, a good example. Like bugs, the development process itself has 
its own life and unexpected turns :-)

Robert