From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109486 invoked by alias); 1 Nov 2018 09:31:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 109473 invoked by uid 89); 1 Nov 2018 09:31:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-3.5 required=5.0 tests=AWL,BAYES_00,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Quick, rapidly, That=e2, 2.29?= X-HELO: EUR01-HE1-obe.outbound.protection.outlook.com Received: from mail-he1eur01on0046.outbound.protection.outlook.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (104.47.0.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Nov 2018 09:31:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BDZaQf7Jzv/O1kK/roCq63Fj69CgbgTiaKL9z/3PiUw=; b=jMVMTnd4Whxm3tgvFktsFG5i6VW29czZE8aQv/8LsoKzO2tAboPaCEY2eqGtrd8tJV94+CYAJJr4tqHcW8Xo/7ILoWty+aAaeaVYwfytWSElAvdQqLmHWpDNZqtOxX8zYa4Uw6Mym4p4NvmjbW/JL0qUoDu2lgWFOG0Yzh8xEN8= Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com (10.172.226.148) by DB6PR0802MB2343.eurprd08.prod.outlook.com (10.172.228.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.26; Thu, 1 Nov 2018 09:31:47 +0000 Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::748a:5f72:2321:bc11]) by DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::748a:5f72:2321:bc11%7]) with mapi id 15.20.1273.028; Thu, 1 Nov 2018 09:31:47 +0000 From: Alan Hayward To: Joel Brobecker CC: GDB Patches , nd Subject: Re: RFC: Changing GDB's version numbering scheme Date: Thu, 01 Nov 2018 09:31:00 -0000 Message-ID: References: <20180910084934.GB3234@adacore.com> <20181031172513.GB4081@adacore.com> In-Reply-To: <20181031172513.GB4081@adacore.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alan.Hayward@arm.com; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: <6F3A4D15B8ADFC4E83A044916B85DD6A@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00001.txt.bz2 DQoNCj4gT24gMzEgT2N0IDIwMTgsIGF0IDE3OjI1LCBKb2VsIEJyb2JlY2tl ciA8YnJvYmVja2VyQGFkYWNvcmUuY29tPiB3cm90ZToNCj4gDQo+IEhlbGxv IGFnYWluLA0KPiANCj4gUXVpY2sgc3VtbWFyeSBvZiB0aGUgZGlzY3Vzc2lv biBzbyBmYXI6IFRoZSBvbmx5IGZlZWRiYWNrIHRoaXMNCj4gZGlzY3Vzc2lv biBkcmV3IHdhcyBuZWdhdGl2ZSBmZWVkYmFjay4gSWYgeW91IHdvdWxkIGxp a2UgdG8gc3VwcG9ydA0KPiB0aGlzIHByb3Bvc2FsLCB5b3Ugc2hvdWxkIHNw ZWFrIHVwOyBvdGhlcndpc2UsIEknbSBpbmNsaW5lZCB0bw0KPiBsZXQgdGhl IG1hdHRlciBkcm9wLg0KDQoNCknigJltIGZvciB0aGlzIGNoYW5nZSBhbmQg YW0gaW4gYWdyZWVtZW50IHdpdGggU2ltb27igJlzIGNvbW1lbnRzLg0KDQpB cyBhIHByb2R1Y3QgbWF0dXJlcywgdGhlIHJlYXNvbnMgZm9yIGFkdmFuY2lu ZyB0aGUgbWFqb3IgbnVtYmVyIHNocmluay4NCk9mdGVuIGl0IGVuZHMgdXAg YmVpbmcgYSDigJxtYXJrZXRpbmfigJ0gZGVjaXNpb24gdG8gYWR2YW5jZSAt IGVsc2V3aGVyZSBJ4oCZdmUNCnNlZW4gbGFyZ2UgaW50ZXJuYWwgY29kZSBy ZWZhY3RvcnMgZ2V0IGJ1bmRsZWQgYXMgYSBtaW5vciByZWxlYXNlIGFuZA0K c21hbGwgaW50ZXJmYWNlIGNoYW5nZXMgY2F1c2UgYSBtYWpvciByZWxlYXNl Lg0KSWYgSSByZW1lbWJlciBpdCByaWdodCwgTGludXggd2FzIHN0dWNrIG9u IDIuNi5YIHVudGlsIGl0IHdhcyBkZWNpZGVkIHRvDQpqdXN0IGNob29zZSB0 aGUgbmV4dCByZWxlYXNlIHRvIGdvIHRvIDMuMC4wLCBhcyB0aGVyZSB3YXMg bm90aGluZyBiaWcNCmVub3VnaCB0byBkZWNsYXJlIGEgbWFqb3IgY2hhbmdl LiBNZWFud2hpbGUgQmludXRpbHMgaXMgc3R1Y2sgb24gMi4zMS4xDQphbmQg R2xpYmMgMi4yOSAoYWx0aG91Z2ggSSB0aGluayB0aGVyZSBhcmUgcmVhc29u cyBmb3IgZ2xpYmMgdG8gbm90DQptb3ZlKS4gSeKAmWQgaG9wZSBnZGIgd291 bGQgbmV2ZXIgZ2V0IHN0dWNrIGFuZCBlbmQgdXAgd2l0aCA4LjI5LjEuDQoN CknigJl2ZSBzZWVuIHByb2R1Y3RzIG1vdmUgdG8gYSB5ZWFyIG51bWJlcmVk IHNjaGVtZSAoZWcgMTkuMSBmb3IgMjAxOSkgdG8NCmF2b2lkIHRoaXMuIFRo YXTigJlzIGFuIGFsdGVybmF0aXZlIGNob2ljZSBmb3IgZ2RiLCBidXQgSSBk b27igJl0IHRoaW5rIHRoZQ0KcmlnaHQgb25lIGhlcmUuDQoNClRoZXJlIGFy ZSByb3VnaGx5IHR3byBtYWluIEdEQiByZWxlYXNlcyBlYWNoIHllYXIsIHNv IGJ5IG1vdmluZyB0byB0aGUNCm5ldyBzY2hlbWUgdGhhdOKAmXMgb25seSB0 d28gYnVtcHMgZXZlcnkgeWVhci4gSXTigJlzIG5vdCBnb2luZyB0byBlc2Nh bGF0ZQ0KcmFwaWRseSBsaWtlIEZpcmVmb3ggYW5kIENocm9tZS4gSW4gMjAy OCwgaXTigJlsbCBiZSBHREIgMjguMSwgd2hpY2ggc291bmRzDQpyZWFzb25h YmxlIHRvIG1lLg0KDQpJZiBHREIgaXMgZ29pbmcgdG8gbW92ZSwgdGhlbiBJ IHRoaW5rIGl0IHNob3VsZCBiZSBpdCBhc2FwLCBiZWZvcmUgR0NDDQpnZXRz IGZhciBlbm91Z2ggYWhlYWQgdGhhdCBHREIgaXNuJ3QgKHJvdWdobHkpIGlu IHN5bmMuDQoNCg0KQWxhbi4NCg0KPiANCj4+IER1cmluZyB0aGlzIHllYXIn cyBHTlUgQ2F1bGRyb24sIHdlIGRpc2N1c3NlZCB0aGUgdmVyc2lvbiBudW1i ZXJpbmcNCj4+IHNjaGVtZSB0aGUgR0RCIHByb2plY3QgaGFzIGJlZW4gZm9s bG93aW5nIHNvIGZhciwgYmVjYXVzZSBhIG51bWJlcg0KPj4gb2YgdXNlcnMg d2VyZSBjb25mdXNlZCBieSBpdC4NCj4+IA0KPj4gQXQgdGhlIG1vbWVudCwg YXMgeW91IGtub3csIEdEQidzIHZlcnNpb24gbnVtYmVyIGlzIGNvbXBvc2Vk IG9mIGF0DQo+PiBsZWFzdCAyIG51bWJlcnMgKE1BSk9SLk1JTk9SKSB3aXRo IGFuIG9wdGlvbmFsIG1pY3JvIHZlcnNpb24gc3VmZml4DQo+PiAoTUFKT1Iu TUlOT1IuTUlDUk8pLiBEdXJpbmcgZWFjaCByZWxlYXNlIGN5Y2xlLCB3ZSB1 c3VhbGx5IGluY3JlYXNlDQo+PiB0aGUgbWlub3IgbnVtYmVyLiBGb3IgaW5z dGFuY2UsIHNpbmNlIHRoZSBsYXN0IHJlbGVhc2UgYnJhbmNoIHdhcw0KPj4g YW4gOC4yIGJyYW5jaCwgdGhlIG5leHQgR0RCIHJlbGVhc2UgYnJhbmNoIGlz IGN1cnJlbnRseSBleHBlY3RlZCB0bw0KPj4gYmUgOC4zLg0KPj4gDQo+PiBU aGUgcHJvYmxlbSB3aXRoIHRoYXQgbnVtYmVyaW5nIGlzIHRoYXQgYSBudW1i ZXIgb2YgdXNlcnMgZ290IGNvbmZ1c2VkDQo+PiBieSB0aGF0IG51bWJlcmlu ZywgdGhpbmtpbmcgdGhhdCBhbGwgcmVsZWFzZXMgbWFkZSB3aXRoIHRoZSBz YW1lIE1BSk9SDQo+PiBudW1iZXIgd2VyZSBtYWRlIGZyb20gdGhlIHNhbWUg cmVsZWFzZSBicmFuY2guIFNvLCB0aGV5IHRob3VnaHQgZm9yDQo+PiBpbnN0 YW5jZSB0aGF0IDguMCwgOC4xIGFuZCA4LjIgd2VyZSBtYWRlIGZyb20gdGhl IHNhbWUgYnJhbmNoLg0KPj4gDQo+PiBUaGUgcHJvcG9zYWwsIHRvIGF2b2lk IHRoaXMgaXNzdWUsIGlzIHRvIGNoYW5nZSB0aGUgdmVyc2lvbiBudW1iZXJp bmcNCj4+IHNjaGVtZSB0byBpbmNyZW1lbnQgdGhlIG1ham9yIHZlcnNpb24g Zm9yIGVhY2ggcmVsZWFzZSBicmFuY2guIFdlIGRpZA0KPj4gbm90IGdvIGlu dG8gdG9vIG11Y2ggZGV0YWlsIGR1cmluZyB0aGUgZGlzY3Vzc2lvbiwgYnV0 IGdlbmVyYWxseQ0KPj4gc3BlYWtpbmcsIHNvIHBhcnQgb2YgdGhlIHByb3Bv c2FsIGJlbG93IGlzIG1lIGV4dHJhcG9sYXRpbmcgaW4gdGVybXMNCj4+IG9m IHNvbWUgb2YgdGhlIGRldGFpbHMgd2hpbGUgdGhpbmtpbmcgdGhpbmdzIHRo cm91Z2ggYSBsaXR0bGUgbW9yZSAtLQ0KPj4gcGxlYXNlIGZlZWwgZnJlZSB0 byBjb21tZW50IGFuZCBwcm92aWRlIG90aGVyIHN1Z2dlc3Rpb25zLg0KPj4g DQo+PiBMZXQncyBhc3N1bWUgdGhhdCB0aGUgbGFzdCByZWxlYXNlIHdlIG1h ZGUgaGFkIGEgbWFqb3IgdmVyc2lvbiBudW1iZXINCj4+IG9mIDxOPiAoaW4g b3VyIGNhc2UsIDxOPiBpcyA4KToNCj4+IA0KPj4gIChhKSBUaGUgbmV4dCBi cmFuY2ggd291bGQgYmUgZ2RiLTxOKzE+LWJyYW5jaA0KPj4gDQo+PiAgKGIp IE9uY2UgdGhlIGJyYW5jaCBpcyBjdXQsIHdlIGluY3JlbWVudCB0aGUgdmVy c2lvbiBudW1iZXIgb24NCj4+ICAgICAgbWFzdGVyIHRvIGJlIDxOKzE+LjUw LkRBVEUNCj4+IA0KPj4gIChiKSBUaGUgZmlyc3QgcHJlLXJlbGVhc2Ugd291 bGQgYmUgbnVtYmVyZWQgIkdEQiA8TisxPi4wLjkwIiBbMl0uDQo+PiAgICAg IEZvciBpbnN0YW5jZSwgb3VyIG5leHQgcHJlLXJlbGVhc2Ugd291bGQgYmUg IkdEQiA5LjAuOTAiLg0KPj4gDQo+PiAgICAgIElmIG1vcmUgcHJlLXJlbGVh c2VzIGFyZSBuZWVkZWQsIHdlIHdvdWxkIHRoZW4gaW5jcmVhc2UNCj4+ICAg ICAgdGhlIE1JQ1JPIG51bWJlciwgc28gIkdEQiA5LjAuOTEiLCBHREIgIjku MC45MiIsIGV0Yy4NCj4+ICAgICAgTm90ZSB0aGF0IGFkZGl0aW9uYWwgcHJl LXJlbGVhc2UgYXJlIGZhaXJseSByYXJlbHkgbmVlZGVkDQo+PiAgICAgIChi dXQgaGF2ZSBvY2Nhc2lvbmFsbHkgaGFwcGVuZWQsIHNvIHdlIG5lZWQgdG8g YmUgcHJlcGFyZWQNCj4+ICAgICAgdG8gZ2VuZXJhdGUgdGhlbSkuDQo+PiAN Cj4+ICAgICAgSSdsbCBleHBsYWluIHRoZSB1c2Ugb2YgbWljcm8gbnVtYmVy cyBhZnRlciB0aGUgcHJvY2VkdXJlDQo+PiAgICAgIGlzIGxhaWQgb3V0ICh0 byBhdm9pZCBjbG9nZ2luZyB0aGUgZ2VuZXJhbCBwcm9jZWR1cmUgd2l0aA0K Pj4gICAgICBkZXRhaWxzKSBbMV0uDQo+PiANCj4+ICAoYykgT25jZSB0aGUg cHJlLXJlbGVhc2UgaXMgb3V0LCB0aGUgdmVyc2lvbiBudW1iZXIgZ2V0cyB1 cGRhdGVkDQo+PiAgICAgIHRvIGluY2x1ZGUgdGhlIGRhdGUgYWdhaW4sIHNv ICI8TisxPi4wLjkwLkRBVEUiLg0KPj4gDQo+PiAgKGQpIFRoZSBmaXJzdCBv ZmZpY2lhbCByZWxlYXNlIG9mZiBhIHJlbGVhc2UgYnJhbmNoIHdvdWxkIGhh dmUNCj4+ICAgICAgdGhlIE1JTk9SIG51bWJlciBzZXQgdG8gIjEiLiBUaHVz OiAiR0RCIDxOKzE+LjEiLg0KPj4gDQo+PiAgICAgIEZvbGxvd2luZyB0aGF0 IHByaW5jaXBsZSwgb3VyIG5leHQgbWFqb3IgR0RCIHJlbGVhc2Ugd2lsbCBi ZQ0KPj4gICAgICBHREIgOS4xLg0KPj4gDQo+PiAgKGUpIE9uY2UgdGhlIEdE QiA5LjEgcmVsZWFzZSBpcyBtYWRlLCB3ZSBzd2l0Y2ggdGhlIGJyYW5jaCdz IHZlcnNpb24NCj4+ICAgICAgdG8gIjxOKzE+LjEuOTAuREFURSIuDQo+PiAN Cj4+ICAoZikgVGhlIG5leHQgb2ZmaWNpYWwgcmVsZWFzZSB3b3VsZCBiZSAi PE4rMT4uMiIuDQo+PiANCj4+ICAoZykgT25jZSAiPE4rMT4uMiIgaXMgb3V0 LCB0aGUgdmVyc2lvbiBudW1iZXIgd291bGQgYmUgc2V0IHRvDQo+PiAgICAg ICI8TisxPi4yLjkwLkRBVEUiIGFnYWluLg0KPj4gDQo+PiAgKGgpIFNhbWUg cHJpbmNpcGxlIGlmIGFkZGl0aW9uYWwgcmVsZWFzZXMgYXJlIG5lZWRlZCAo IjxOKzE+LjMiLCBldGMpLg0KPj4gDQo+PiBbMV0gT25lIHByb3BlcnR5IEkg d2FudGVkIHRvIGhhdmUgaW4gdGhlIHByb2NlZHVyZSBhYm92ZSB3YXMgdG8g aGF2ZQ0KPj4gICAgYSBjb25zaXN0ZW50IG1pbm9yIG51bWJlciBmb3IgdGhl IGZpcnN0IG9mZmljaWFsIHJlbGVhc2UsIHNvIGFzIHRvDQo+PiAgICBrbm93 IHRoYXQgR0RCIDxYPi4xIGlzIGFsd2F5cyB0aGUgZmlyc3Qgb2ZmaWNpYWwg cmVsZWFzZSBmcm9tIGJyYW5jaA0KPj4gICAgPFg+LiAgQ29tYmluZWQgd2l0 aCB0aGUgcG90ZW50aWFsIG5lZWQgZm9yIG11bHRpcGxlIHByZS1yZWxlYXNl cywNCj4+ICAgIGFuZCB0aGUgZmFjdCB0aGF0IHdlIHdhbnQgdG8gaGF2ZSBp bmNyZWFzaW5nIHZlcnNpb24gbnVtYmVycywgYW5kDQo+PiAgICBkYXRlZCB2 ZXJzaW9uIG51bWJlcnMgaW4gYmV0d2VlbiwgdGhlIG9ubHkgd2F5IEkgZm91 bmQgd2FzIHRvIHVzZQ0KPj4gICAgdGhlIDxYPi4wLjlYIHJhbmdlLg0KPj4g DQo+PiAgICBPbmUgYWx0ZXJuYXRpdmUgdG8gdXNpbmcgPE4rMT4uMC45MCBm b3IgcHJlLXJlbGVhc2Ugd291bGQgYmUgdG8gdXNlDQo+PiAgICA8Tj4uOTAu IEl0J3MgYSBzaG9ydGVyIHZlcnNpb24gbnVtYmVyLCBhbmQgSSB3b3VsZCBi ZSBPSyB3aXRoIHRoYXQsDQo+PiAgICBidXQgbXkgc2Vuc2UgaXMgdGhhdCBp dCdzIGtpbmQgb2YgY29uZnVzaW5nIHRoYXQgYSBwcmUtcmVsZWFzZQ0KPj4g ICAgd291bGQgaGF2ZSBhIGRpZmZlcmVudCBtYWpvciB2ZXJzaW9uLg0KPj4g DQo+PiBbMl0gTWlub3Igbm90ZTogSW4gdGhlIG1ham9yaXR5IG9mIHRoZSBy ZWxlYXNlIGN5Y2xlcywgd2UgY3JlYXRlIHRoZSBmaXJzdA0KPj4gICAgcHJl LXJlbGVhc2UgcmlnaHQgYWZ0ZXIgdGhlIGJyYW5jaCBpcyBjdXQuIEhvd2V2 ZXIsIHRoZXJlIGhhdmUgYmVlbg0KPj4gICAgY3ljbGVzIGluIHRoZSBwYXN0 IHdlcmUgd2Ugd2FudGVkIHRvIHdhaXQgZm9yIHNwZWNpZmljIGZpeGVzIGJl Zm9yZQ0KPj4gICAgY3JlYXRpbmcgdGhlIGZpcnN0IHByZS1yZWxlYXNlLiBJ biB0aG9zZSBzaXR1YXRpb25zLCB0aGUgZmlyc3QNCj4+ICAgIHByZS1yZWxl YXNlIHdpbGwgYmUgIjxOKzE+LjAuOTEiIGluc3RlYWQuIEkgZG9uJ3QgdGhp bmsgaXQgcmVhbGx5DQo+PiAgICBpcyBhbGwgdGhhdCBpbXBvcnRhbnQuDQo+ PiANCj4+IFRob3VnaHRzPyBJZiB3ZSBhZ3JlZSwgSSB3aWxsIHVwZGF0ZSBn ZGIvdmVyc2lvbi5pbiwgYW5kIGxvb2sgYXQgdGhlDQo+PiBkb2N1bWVudGF0 aW9uIHVwZGF0ZS4NCj4+IA0KPj4gLS0gDQo+PiBKb2VsDQo+IA0KPiAtLSAN Cj4gSm9lbA0KDQo= >From gdb-patches-return-152051-listarch-gdb-patches=sources.redhat.com@sourceware.org Thu Nov 01 10:44:32 2018 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 87303 invoked by alias); 1 Nov 2018 10:44:32 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 87291 invoked by uid 89); 1 Nov 2018 10:44:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:sk:k3-v6mr X-HELO: mail-wm1-f52.google.com Received: from mail-wm1-f52.google.com (HELO mail-wm1-f52.google.com) (209.85.128.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Nov 2018 10:44:29 +0000 Received: by mail-wm1-f52.google.com with SMTP id p2-v6so938456wmc.2 for ; Thu, 01 Nov 2018 03:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=yVuB09trGlcIvnJvAILISJ9ljkm6R7zI5sskbbHhIDE=; b=HDxqWg8AIxGExiMT1iu0zryUt8g4VtshAUI1B8RFLiGFrjg7e0Eo/LtYKFEeyJkUjf xWKRIKKGWhUJm3bSIKCwUih+XakPHxUyL5nFl27fIGhhChX3RWfLI/xPV/XrkRSk+gkw gcYiAIX88BJVipSANJmitAhSPbAPHUHVBVnhLuxsPR3dMm1gP++li2txqyhqqY6GMrNf SWkHV82wB/nnFKJBwiIuLLMJXm32V9Oyak1I5J2sXxZ2CgJFUv1aNdUEpG1HGwEF9ZvC eL1g2tWBSJEVoj1VY+jv+fB+W3aLLvIroBx5NVxeof1HYE1L/IOly1Dtcr6ALmtcZvIr ApMQ== Return-Path: Received: from localhost (host81-148-252-35.range81-148.btcentralplus.com. [81.148.252.35]) by smtp.gmail.com with ESMTPSA id 4-v6sm10863498wmg.21.2018.11.01.03.44.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 01 Nov 2018 03:44:26 -0700 (PDT) Date: Thu, 01 Nov 2018 10:44:00 -0000 From: Andrew Burgess To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: RFC: Changing GDB's version numbering scheme Message-ID: <20181101104424.GQ15098@embecosm.com> References: <20180910084934.GB3234@adacore.com> <20181031172513.GB4081@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181031172513.GB4081@adacore.com> X-Fortune: Terorists crashed an airplane into the server room, have to remove /bin/laden. (rm -rf /bin/laden) X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00002.txt.bz2 Content-length: 5469 * Joel Brobecker [2018-10-31 10:25:13 -0700]: > Hello again, > > Quick summary of the discussion so far: The only feedback this > discussion drew was negative feedback. If you would like to support > this proposal, you should speak up; otherwise, I'm inclined to > let the matter drop. I would support changing the numbering scheme. The problem I see with the current scheme is that I don't understand what the criteria is for bumping the major version number. Maybe it's one of those things that you'll just know it when you see it. For me the concern that the new scheme could cause confusion is not a big one, under both the old and new scheme version 10.1 is "better" than 9.1, and 9.2 is "better" than 9.1. The only difference is that under the new scheme 9.2 is more closely related to 9.1 than it used to be. Most users I suspect only care about finding the "best" release currently available. In the rare case that someone feels that they really can't move onto a new GDB branch for *reasons*, then they might not move from 9.1 to 9.2 because that used to mean a new branch. This is easy enough to solve by just rewording the website to make it clear that 9.2 is the next release for the v9 branch. Thanks, Andrew > > > During this year's GNU Cauldron, we discussed the version numbering > > scheme the GDB project has been following so far, because a number > > of users were confused by it. > > > > At the moment, as you know, GDB's version number is composed of at > > least 2 numbers (MAJOR.MINOR) with an optional micro version suffix > > (MAJOR.MINOR.MICRO). During each release cycle, we usually increase > > the minor number. For instance, since the last release branch was > > an 8.2 branch, the next GDB release branch is currently expected to > > be 8.3. > > > > The problem with that numbering is that a number of users got confused > > by that numbering, thinking that all releases made with the same MAJOR > > number were made from the same release branch. So, they thought for > > instance that 8.0, 8.1 and 8.2 were made from the same branch. > > > > The proposal, to avoid this issue, is to change the version numbering > > scheme to increment the major version for each release branch. We did > > not go into too much detail during the discussion, but generally > > speaking, so part of the proposal below is me extrapolating in terms > > of some of the details while thinking things through a little more -- > > please feel free to comment and provide other suggestions. > > > > Let's assume that the last release we made had a major version number > > of (in our case, is 8): > > > > (a) The next branch would be gdb--branch > > > > (b) Once the branch is cut, we increment the version number on > > master to be .50.DATE > > > > (b) The first pre-release would be numbered "GDB .0.90" [2]. > > For instance, our next pre-release would be "GDB 9.0.90". > > > > If more pre-releases are needed, we would then increase > > the MICRO number, so "GDB 9.0.91", GDB "9.0.92", etc. > > Note that additional pre-release are fairly rarely needed > > (but have occasionally happened, so we need to be prepared > > to generate them). > > > > I'll explain the use of micro numbers after the procedure > > is laid out (to avoid clogging the general procedure with > > details) [1]. > > > > (c) Once the pre-release is out, the version number gets updated > > to include the date again, so ".0.90.DATE". > > > > (d) The first official release off a release branch would have > > the MINOR number set to "1". Thus: "GDB .1". > > > > Following that principle, our next major GDB release will be > > GDB 9.1. > > > > (e) Once the GDB 9.1 release is made, we switch the branch's version > > to ".1.90.DATE". > > > > (f) The next official release would be ".2". > > > > (g) Once ".2" is out, the version number would be set to > > ".2.90.DATE" again. > > > > (h) Same principle if additional releases are needed (".3", etc). > > > > [1] One property I wanted to have in the procedure above was to have > > a consistent minor number for the first official release, so as to > > know that GDB .1 is always the first official release from branch > > . Combined with the potential need for multiple pre-releases, > > and the fact that we want to have increasing version numbers, and > > dated version numbers in between, the only way I found was to use > > the .0.9X range. > > > > One alternative to using .0.90 for pre-release would be to use > > .90. It's a shorter version number, and I would be OK with that, > > but my sense is that it's kind of confusing that a pre-release > > would have a different major version. > > > > [2] Minor note: In the majority of the release cycles, we create the first > > pre-release right after the branch is cut. However, there have been > > cycles in the past were we wanted to wait for specific fixes before > > creating the first pre-release. In those situations, the first > > pre-release will be ".0.91" instead. I don't think it really > > is all that important. > > > > Thoughts? If we agree, I will update gdb/version.in, and look at the > > documentation update. > > > > -- > > Joel > > -- > Joel