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

[Dan Pascu]

On Friday 04 April 2008, Henning Westerholt wrote:
> 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

I do not think that less often releases would help a bit. On the contrary 
they would probably make it worse. I would release often, but I would try 
to have a more incremental approach, so that releases do not differ that 
much.

> 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

This siptrace stuff is just one of the many changes that will make 
migrating from 1.3 to 1.4 harder than necessary, even more considering 
that there is a possible good solution for this, but apparently opposed 
because it takes more effort to do it than to just work around the 
problem. But by working around the problem, we only make sure it'll 
happen again in the future.

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

Bugs/changes can be minimized if we give the design phase a bit more 
consideration, before jumping into coding something.

>
> If you don't want to update every six months, feel free to use a stable
> branch. 

I use a stable branch, but that changes every 6 months and experience 
shows that it always did in major ways.

> If you run out of the maintenance window of the project, you 
> need to do some work by yourself. But its definitely manageable.

This doesn't mean that it can't be improved and the amount of management 
we need to do to move forward be minimized.

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

Any name may be a bad choice as long as I have to consult 4 database docs 
for keywords that may not overlap. Of course we can use names like 
this_name_hopefully_is_not_a_keyword to avoid it :P

-- 
Dan