Re: Putting the 'Mono debate' back on the rails
- From: Ghee Teo Sun COM
- To: Elijah Newren <newren gmail com>
- Cc: Joe Shaw <joeshaw novell com>, GNOME Desktop Hackers <desktop-devel-list gnome org>
- Subject: Re: Putting the 'Mono debate' back on the rails
- Date: Mon, 24 Jul 2006 16:11:47 +0100
Elijah Newren wrote:
On 7/24/06, Ghee Teo sun com <Ghee Teo sun com> wrote:
Mike Kestner wrote:
> My Gtk#-lite 2.16 binding would be allowed to break API in 2.18 as
long
>
>as I make it parallel-installable, thereby breaking all existing
>Gtk#-lite applications unless packagers provide Bindings release 2.16
>with their 2.18 desktop
parallel-instabllable is the worst idea of software development.
One ended with forked version of software and only create more
maintaineable nightmare. We are all tremendous hackers/engineers,
so stick to some good engineering principles :)
Huh? Would you really want gtk+-2.x to use the same library name as
gtk+-1.x, breaking all gtk+-1.x apps? It's not even close to the
worst idea. It's actually a very good idea -- when not overused. In
particular, combined with each version remaining stable,
parallel-installable is far better than just breaking API/ABI.
Good case. But gtk+1.x and gtk+2.x is more of the exception than norm.
Didn't know how much maintaining the the gtk+ engineers still have to work
on gtk+1.x, though? I can't imagine gtk+ want to do anything as dramatics
as this anytime soon.
The other example is gstreamer, I am sure they can share with us whether
their decision to go with parallel-installable version of 0.8 and 0.10 was a
pleasant exercise. Of course they were facing similar situations as is now.
Of course, nothing is worst than causing a break in the applications
because
we change the API underneath. So therefore, it may it all the more the gtk#
should be integrated into GNOME in the right libraries division, not?
Because
we don't want GNOME developers to keep remember which version of the API
to use.
-Ghee
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]