From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a17:906:a205:b0:a52:4db9:938b with SMTP id r5csp1861726ejy; Fri, 3 May 2024 05:36:11 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVtRxTxGsIcMStf238Reej5sISANt06aq3w9oI4XwfVV7nBdCdhwS8XgefXDxZQEwuKpMPw+pGvYPo/V9OjUXyJCv+VuXEn X-Google-Smtp-Source: AGHT+IG+GCzwCb58+MhMBNppsW0GdYJc46rFaMuUFkiRn9MPYqDzsKp4250I6w8nSR4nmRr6DSR0 X-Received: by 2002:a05:620a:29d0:b0:790:d62a:d9fa with SMTP id s16-20020a05620a29d000b00790d62ad9famr3249502qkp.7.1714739770921; Fri, 03 May 2024 05:36:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1714739770; cv=none; d=google.com; s=arc-20160816; b=h4dyaha6MReS63hUAB9bXZPbDcE78p8HOJnOtGO1XJVUvsSJ8ddy2rTqCoR0HrIghO wRMwIQ41a8znsrpiLrvPf+D6avXgLdbQxzY1mZCPrp+fXzZeY9jwT0FRGy06fTZR+TDu RO1dVkFdYELX84udWXm8tPW0gdYv+GrM+rb70DLUtR3GvjvGcu1Qo78JlhC83Dz1YAMK FrNH+oaQAFI9XK3Nvkqq74z7ZjbS88zFYxWgEQXuxljSBbd1/4BXWlhQEf8YNNVqO/gG F27glOveaN5kd3Nz4pjdbkpna+CKh2HAAtJ29POAZazYe9zBsubjarmznQHkRpjzOdjW WdPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:user-agent :in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=pWj+HnS8N6/jcUpATLvn3zKB5cbBEMbtsZN5xw5kBws=; fh=9PeifdOIeHGG/Fq/8EqfoUCtxr7mCL9Xl2smON729J8=; b=TQJB6rUE1RJVLYRBBnUfHlKWH/reqs8ZenNDZF4tbYoqIjOmqYABYIExmjnvVkKaF4 /ffTmyGgI65SCjpTEUxywTr71Xwo4t3Ziw652Q0quf7iDVP2zAZj3T5YyYCEv7FeoSlB ag21USeM5UMe6xg+Uodsty9zImQu9nsHCEEABYPSEIkUsgYeG7+TIWUs2pOLD8V4rj9S f2Xf5bEvFzJbryiHbEHRr4w5QC+5bMj4HPlZL/DfhT6jF0NglGmI1GLzVZ/STpQ1+wUp W3CTQqM9QwwRrfEVfUDWL0733fJbht/Zrk/SgGLKBw6DcMtZ2SdKpkaprKjhBzCWbtUm Rbtg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hCiTcJu9; spf=pass (google.com: domain of qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org. [209.51.188.17]) by mx.google.com with ESMTPS id s10-20020a05620a29ca00b0078ed8a2e55asi3528516qkp.267.2024.05.03.05.36.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 May 2024 05:36:10 -0700 (PDT) Received-SPF: pass (google.com: domain of qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hCiTcJu9; spf=pass (google.com: domain of qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2s8w-0007uB-QT; Fri, 03 May 2024 08:36:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s2s8E-0007Fo-Bm for qemu-devel@nongnu.org; Fri, 03 May 2024 08:35:20 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s2s8A-0002nZ-9T for qemu-devel@nongnu.org; Fri, 03 May 2024 08:35:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1714739707; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pWj+HnS8N6/jcUpATLvn3zKB5cbBEMbtsZN5xw5kBws=; b=hCiTcJu9bROqKfo9Hb0IKv/4diCeHIYKDBnH4bJr6jii68a2hrNeb6iv7l1dklIIExFJDH NS1CLVzZ99qubgEYHdcc/QkFqojR0YT7SBX2Kb1mOvNKHqs7nadbgbELEYGuLFANaWEoj0 brQDsqZHoBHODnrQg/74jeOM+aoCDps= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-29-n7i_lRwhMVOmwufLibs9aQ-1; Fri, 03 May 2024 08:35:04 -0400 X-MC-Unique: n7i_lRwhMVOmwufLibs9aQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 72F5A886F07; Fri, 3 May 2024 12:35:03 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.62]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8A93A40C6CC0; Fri, 3 May 2024 12:34:59 +0000 (UTC) Date: Fri, 3 May 2024 13:34:57 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Peter Maydell Cc: qemu-devel@nongnu.org, Harsh Prateek Bora , Nicholas Piggin , Richard Henderson , Yanan Wang , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Thomas Huth , =?utf-8?Q?C=C3=A9dric?= Le Goater , Halil Pasic , Laurent Vivier , qemu-arm@nongnu.org, Daniel Henrique Barboza , Eduardo Habkost , qemu-ppc@nongnu.org, David Gibson , Ilya Leoshkevich , Eric Farman , Christian Borntraeger , "Michael S. Tsirkin" , Paolo Bonzini , Marcel Apfelbaum , David Hildenbrand , qemu-s390x@nongnu.org Subject: Re: [PATCH 00/14] hw: define and enforce a standard lifecycle for versioned machines Message-ID: References: <20240501182759.2934195-1-berrange@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 Received-SPF: pass client-ip=170.10.129.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.483, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Errors-To: qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org Sender: qemu-devel-bounces+alex.bennee=linaro.org@nongnu.org X-TUID: 7CVa/JFjuAwJ On Fri, May 03, 2024 at 01:14:27PM +0100, Peter Maydell wrote: > On Wed, 1 May 2024 at 19:28, Daniel P. Berrangé wrote: > > I wonder, however, whether we would benefit from changing how we > > update the VERSION file. > > > > eg instead of re-using the micro digit to indicate a dev or rc > > snapshot, represent those explicitly. eg "9.1.0-dev" and > > "9.1.0-rc1", "9.1.0-rc2", etc in VERSION. > > > > We don't use the full QEMU_VERSION in the code in all that many > > places. It appears in some help messages for command line tools, > > and in QMP query-version response, and in a few other misc places. > > At a glance it appears all of those places would easily handle a > > tagged version. > > > > For release candidates in particular I think it would be saner > > to show the user the actual version the release is about to become, > > rather than the previous release's version. This would make the > > reported version match the rc tarball naming too which would be > > nice. > > I think the theory behind the VERSION file is that we want > to be able to express the version: > * purely numerically > * in a strictly ascending order > > We expose the assumption of numeric versions in places like > QMP's query-version command, which reports it as a set of ints. Right, we have: # -> { "execute": "query-version" } # <- { # "return":{ # "qemu":{ # "major":0, # "minor":11, # "micro":5 # }, # "package":"" # } # } We could add an extra field to it thus: # -> { "execute": "query-version" } # <- { # "return":{ # "qemu":{ # "major":0, # "minor":11, # "micro":5, # "tag": "rc2" # }, # "package":"" # } # } arguably we are still in strictly ascending order for the numeric part, we merely didn't bump the numeric part of the value at rc releases. > I think there's probably scope for making the "human friendly" > version string be surfaced instead of the strictly-numeric > one in more places, but I worry that breaking the "always > numeric and ascending" rule might have subtle breakage for > us or for downstream uses... Downstream I see no issues. There are already many projects which use a '-dev' or '-rcNN' suffix for tarballs of unreleased versions, and distros have guidelines on how they deal with this. In fact downstream already deals with it for QEMU, because they will typically set packaging versioning based on the version as seen in the tarball name, not the different version seen in the VERSION file (and thus QMP). With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|