On Tue, Mar 9, 2010 at 1:38 AM, Vincent Snijders <[email protected]> wrote: > Alexander Klenin schreef: >> >> On Tue, Mar 9, 2010 at 13:44, Hans-Peter Diettrich <[email protected]> >> wrote: >>> >>> It's not so simple. Guess why it took me more than a year to implement >>> usable docking - it's not a matter of implementation, but a matter of >>> discussions what is *allowed* to change in a poor interface, and what >>> additional LCL/Delphi incompatibilities already have been introduced and >>> must be respected by all new code. It's almost impossible to replace an >>> inappropriate implementation by a better model, because some existing >>> code >>> *could* be broken by such an change - unless such a suggestion comes from >>> a >>> core developer, who simply changes his existing code. >>> >> >> I wholeheartedly agree with the above -- a purely theoretical >> backwards incompatibility >> issue already prevented me from contributing to at least one Lazarus >> subsystem. >> > > I wonder how such wishes can be reconciled with wishes from Tom Lisjac for > example to have more stable lazarus, not changing compatibility every > release (if that is what actually happens).
I don't remember suggesting that compatibility should never change between major releases. What we've been talking about in this thread is for stability issues to *start* being considered and to *begin* managing changes so version impacts on production developers and existing code would be minimized or at least well documented. Borland always did this with new version releases, so when they made changes, the community understood and was fully prepared for them. The "stability issue" occurs when arbitrary changes are tossed in randomly and without regard for their impact existing code... and with no documentation. This doesn't mean that there has to be total compatibility between a version 1.0 and 2.0 if necessary changes and their impact on existing code are clearly documented. It also won't be an easy or straightforward process managing codebreaking decisions because there will always be genuinely good reasons to make changes... but starting the process of managing code impacting changes is an essential next step if there's ever going to be a credible 1.0, 2.0, 3.0... etc for this project. This thread was simply intended to flag a real world problem that developers are having when trying to create production code with this tool. Many of us were hoping to see a civil discussion of that topic that might have even lead to finding a mutually agreeable solution. I'm sorry that didn't happen but I'm hoping it will at a later time... and definitely before a serious effort is made to release a 1.0. -Tom -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
