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

[Dan Pascu]

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? :)

>
> 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.

-- 
Dan