From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-24102-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 26629 invoked by alias); 27 Jan 2006 16:11:17 -0000
Received: (qmail 26488 invoked by uid 22791); 27 Jan 2006 16:11:17 -0000
X-Spam-Check-By: sourceware.org
Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jan 2006 16:11:15 +0000
Received: from list by ciao.gmane.org with local (Exim 4.43) 	id 1F2WBE-0001ZP-UU 	for gdb@sources.redhat.com; Fri, 27 Jan 2006 17:10:33 +0100
Received: from zigzag.lvk.cs.msu.su ([158.250.17.23])         by main.gmane.org with esmtp (Gmexim 0.1 (Debian))         id 1AlnuQ-0007hv-00         for <gdb@sources.redhat.com>; Fri, 27 Jan 2006 17:10:32 +0100
Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian))         id 1AlnuQ-0007hv-00         for <gdb@sources.redhat.com>; Fri, 27 Jan 2006 17:10:32 +0100
To: gdb@sources.redhat.com
From:  Vladimir Prus <ghost@cs.msu.su>
Subject:  Re: MI -break-info command issues
Date: Fri, 27 Jan 2006 16:44:00 -0000
Message-ID:  <drdgkk$qt1$1@sea.gmane.org>
References:  <dr5csi$bg2$1@sea.gmane.org> <dr9s4n$rsf$1@sea.gmane.org> <ulkx2en42.fsf@gnu.org> <200601271115.22939.ghost@cs.msu.su> <ufyn9euj6.fsf@gnu.org> <drdchc$672$1@sea.gmane.org> <20060127151220.GA978@nevyn.them.org> <drdfb3$kpb$1@sea.gmane.org> <20060127155132.GA8843@nevyn.them.org>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7Bit
User-Agent: KNode/0.8.2
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2006-01/txt/msg00302.txt.bz2

Daniel Jacobowitz wrote:

>> The problem with existing frontends can probably be solved by posting a
>> prominent message to mailing list whenever MI output is going to change.
>> Or using versioning.
> 
> This has been discussed before plenty of times.  We will make
> incompatible changes to MI from time to time; but IMO that doesn't
> justify making _unnecessary_ incompatible changes.
> 
> Like Bob, I wouldn't have added the fields.  But since they are
> present, I see no reason to remove them.

Ok, understood. It would be good, though, if MI docs contained some
introduction chapter that would state this policy. That'd prevented this
thread from ever starting.

- Volodya