Release Schedules and Feedback on Fixes

[Robert Brenstein]

>  > In my personal opinion, branching is essential if Valentina is to
>>  become a serious enterprise player and has so far been sorely ignored
>>  aspect of the product strategy.
>
>Main reason I think, because we have TWO groups of developers.
>For example:
>
>     we have 2.4.3 in 15 September
>     we have 2.5 in 25 Nov.
>
>Not big period. Right? It is not even fast 6-months release model.
>
>1) We have group of people who have meet bugs in 2.4.3.
>They want fix of bugs. Timeline of all found fixes 1.5-2 months.
>
>2) second group say: we need SSL and Bonjour tomorrow to make our projects.
>
>- So me and Ivan have work on bugs.
>- Ivan also have work on SSL.
>- Kiril have work independently on Bonjour.
>- Sergey have work on PIVOT and WITH
>- other developers separate tasks and VStudio.
>
>SSL and Bonjour do not affect engine and not bring new bugs. We see this
>perfectly.
>
>We run our regression tests to see that we not break EXISTED functionality.
>So where is problem?
>
>--------
>So far I do not hear that e.g. 2.5 have break something from existed
>functionality.
>
>We have found with Jon, that some of his troubles was because he did have
>users with 2.0 (!!!) dbs format made on PPC and they have move in September
>first time to INTEL using V4RB UB 2.4.3. Bug was in convert 2.0 -> 2.3.
>It is fixed now in 2.5 also.
>
>Agree - very rare bug. Users which already was on 2.3, 2.4.1, 2.4.2, ...
>Will not meet this problem...
>
>
>--------
>So I try protect our team that we really bring new bugs in each 2.x.
>I very doubt. Protection from this is - regression tests.
>
>
>--
>Best regards,
>
>Ruslan Zasukhin
>VP Engineering and New Technology
>Paradigma Software, Inc


Ruslan, you are focusing here on some specific issues of the newest 
releases. Yes, some bug fixes and new features were now orthogonal, 
so should not affect each other, and some reported bugs were user 
faults. This is, however, not so obvious to someone checking Mantis 
for what was changed in a given release. Automated testing is good 
and needed, but it is a different aspect.

We are talking about a more general issue of product development. If 
I am using 2.4.1 and update to 2.4.2 I truly expect only a few bug 
fixes and nothing more. If I upgrade to 2.5.1 I expect the same bug 
fixes but also some new features. Yes, the issue is of logically 
separating bug fixes from new features and enhancements in a life of 
a product.

Capability to maintain various code version and specifically 
branching is the reason for existence of CVS, Subversion, and several 
other products. It seems you do not use it to the full benefit of 
yours and ours.

Branching can, for example, help you in identifying some bugs. If 
database corruptions are being reported for, let's say, 2.4.3 and 
2.5.1, you may prefer to hunt them in 2.4.3 since you can be certain 
that there is no code change affecting anything. I mean code coming 
from adding new features or improvements in 2.5. Once a bug is fixed 
in 2.4 branch, CVS allows you to easily merge the fix from 2.4 branch 
into the head branch, 2.5 in this example. You can also use sticky 
tags to identify code status as it was for each public release while 
offering daily builds of the head and last official release for beta 
testers. Again more flexibility for you at expense of little extra 
work. Some new features may actually be developed in their own 
private branch and merged into head branch only after sufficient 
testing.

Robert