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

[Henning Westerholt]

On Friday 04 April 2008, Dan Pascu wrote:
> [..]
> One of the issues I saw with almost every release of openser since 1.0.0
> is the major disruptive changes that were in all of them. There was no
> release since then where I didn't have to completely rewrite my config
> script, alter my db schemas and update applications to use the new db
> schemas. The fact that after a release it can take up to a month to
> adjust the old environment to the new release and sort out all bugs,
> makes it a very innefficient approach when the release cycle is 6 months.
> This is why I would suggest we should generally use a less disruptive
> approach to things that minimized the migration path, especially if
> available and especially when (like in this case) would completely solve
> the problem rather than working it around.

Dan,

i understand your concerns, we all faces the same issues. But what are the 
alternatives? Release only every 12 month or so means only even more update 
pain and bugs. Its also hard to do prober testing with such a release. Do 
only minor changes? First of all, how do you qualifiy a minor change? For me 
the siptrace stuff we're now discussing is such a one, for you not. I think 
most people care mostly about the stuff that there using intensivly, but this 
sets don't overlap necessarily that much. Breakage and bugs are the price we 
pay for the progress we've made.

If you don't want to update every six months, feel free to use a stable 
branch. If you run out of the maintenance window of the project, you need to 
do some work by yourself. But its definitely manageable.

If you think there is a better solution for some change, i welcome any 
complains. But they will not change anything, the claims need to supported 
with some code, research work, whatever. (This don't qualify of course for a 
change that is plain wrong, or rejeced from the majority of the developers.) 
Sure, it would be great if we had a mean of proper quoting the colum names, 
but for now this is not available. Daniel also aggreed that this name was a 
poor choice in the first time.

Best regards,

Henning