[OpenSER-Devel] SF.net SVN: openser: [3972] trunk

[Daniel-Constantin Mierla]

On 04/04/08 13:38, Dan Pascu wrote:
> On Friday 04 April 2008, Daniel-Constantin Mierla wrote:
>   
>>> I can understand that some things need to be improved, but I was
>>> pointing out that this kind of major refactoring between minor
>>> releases shouldn't be the norm.
>>>       
>> Apache does versioning with major release as first number, we say major
>> release based on middle number change. The difference is that we do
>> major releases more often.
>>     
>
> Apart from that being confusing, considering the well established 
> consensus followed by most projects using a major.minor.micro numbering 
> scheme, what is the 1st number standing for in openser and what will 
> happen when it changes, considerig that the middle number brings such 
> significant changes? :)
>   
Last time was done when openser was compliant with RFC at the required 
transport layer (e.g., tls) and not much
related to major changes in the architecture, being short after 0.9.x. I 
guess this is an open discussion issue.
>   
>> I agree that backward compatibility should be enforced as much as
>> possible, but should take in consideration:
>> - the effort to implement it
>> - the complexity it adds
>> - how big effects has the change in openser
>>     
>
> It is my opinion that most of the backward compatibility issues we have 
> faced, as well as the major refactoring that happens between 2 releases, 
> is caused by rushing in new features without a proper design/evaluation 
> phase that would try to sort out potential future issues and minimize the 
> number of design changes that will be done later. That combined with the 
> 6 month release schedule and the fact that between 2 releases openser 
> becomes very quickly unstable to the point that almost none uses it to 
> test the new features, results in the fact that nobody notices issues 
> with the new features until after a new openser is released, or even only 
> after 2-3 releases. Then it gets down the major change path, but still 
> not overviewed/tested enough because openser is unstable again between 
> releases. The number of bugs that are fixed immediately after a release, 
> confirms my hypothesis that almost none does test openser inbetween or 
> immediately before a new release, which aggravates the issue.
>   
The fact is that everybody tests with its own configuration and need. 
openser is a complex platform, an god knows how many combinations you 
can use to get practically the same functionality at the end, all 
different and each exposed to other bugs. Testing suite introduced by 
Henning is a big step forward. And yes you are right about the bugs 
following shortly the release, but I believe that no matter how long is 
the testing period, one week or 6months, those bugs will be discovered 
after the release. Many are distribution specific, others relevealed by 
custom configs, the people that usually participate in the testing phase 
have low chance to discover them.

Daniel

-- 
http://www.asipto.com