[Lazarus] Wanted: new maintainer for git mirror

[Vincent Snijders]

On Tue, Mar 9, 2010 at 1:38 AM, Vincent Snijders
<vsnijders at vodafonevast.nl> wrote:
> Alexander Klenin schreef:
>>
>> On Tue, Mar 9, 2010 at 13:44, Hans-Peter Diettrich <DrDiettrich1 at aol.com>
>> 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