[OpenSER-Devel] SF.net SVN: openser: [3972] trunk
Henning Westerholt
henning.westerholt at 1und1.de
Fri Apr 4 11:36:52 CEST 2008
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
More information about the Devel
mailing list