From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Reconsider defaults for use-package-vc-prefer-newest Date: Fri, 27 Sep 2024 09:46:39 +0300 Message-ID: <86v7yh8ugg.fsf@gnu.org> References: <87wmj7dftf.fsf@posteo.net> <87setvxyt6.fsf@gmail.com> <87jzf7o13b.fsf@posteo.net> <87msk3jr0u.fsf@gmail.com> <87setum5do.fsf@posteo.net> <87msk1520e.fsf@gmail.com> <87settknf1.fsf@posteo.net> <87tte8akwa.fsf@gmail.com> <878qvjaep6.fsf@posteo.net> <87cykvwixn.fsf@gmail.com> <3BC7EB33-504C-4532-A2DF-83712B64878E@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30513"; mail-complaints-to="usenet@ciao.gmane.io" Cc: suhailsingh247@gmail.com, emacs-devel@gnu.org, philipk@posteo.net, meedstrom@runbox.eu, tonyzorman@mailbox.org To: Charles Choi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 27 08:47:53 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1su4lc-0007ml-Qv for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Sep 2024 08:47:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1su4kl-0005UU-44; Fri, 27 Sep 2024 02:46:59 -0400 Original-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 1su4kc-000537-Pm for emacs-devel@gnu.org; Fri, 27 Sep 2024 02:46:55 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1su4kV-0007OZ-T9; Fri, 27 Sep 2024 02:46:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Bvd+6vGNrzg4+3bC41cwsCZBCEdY9dnDqhBksQsjFGs=; b=Le2M1tEYgsT5TZnL6d4s hRXhAAnAcp3MXfLaMOAd9WiwaKZYqz4i0IFOkY3kMDPTboyuoTjFlw+UtUHGcjMkf1pY/owesOi/0 edgLq1LeEer2Jz9CXrt0itUbzVzUDKBybeMvoJ7UnZ9UeMSvtR5SWzU3BLiOSGAl+6kYxuG0putf+ 9xrJHf30IS5FrpjjdXMA89zOI1yt1wKan8EA+Rg7D5XbzLN+8iA5LYUzl4gA/sbnScUSilkhcfnJr HSanEk8kHE2QkPvNnOCfhx4G/bsHKVIlHZv6j0G4RGmprtNYylvOtxFtefw0AnSt9mHU9Me7LCKAy EOkHXfaW0SjsIQ==; In-Reply-To: <3BC7EB33-504C-4532-A2DF-83712B64878E@gmail.com> (message from Charles Choi on Thu, 26 Sep 2024 16:23:22 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324127 Archived-At: > From: Charles Choi > Date: Thu, 26 Sep 2024 16:23:22 -0700 > Cc: Philip Kaludercic , > Martin Edström , > Tony Zorman > > As my package `casual-dired` has been mentioned in this thread, I'd like to understand better what the recommended practice for package versioning is. > > At current my development practice is to: > > - Create a feature branch from the `main` branch and bump the `Version:` header. > - Make commits to the feature branch. > - Merge the feature branch back to `main`. > - Tag `main` with the `Version:` header value. > > The above practice seems to violate whatever logic is being used to determine if a package is versioned correctly as it raises a COMMIT MISMATCH warning. My interpretation of this is that the `Version:` header is being used to track the build of a package which seems to me too strict. As long as the tag is in sync with the `Version:` header, I think it should be fine as a package can have many files. The above seems to indicate there's some kind of bug in deciding whether there's a commit mismatch, because I don't see anything wrong with what you do. As long as the version tag tags the commit where the corresponding "Version:" entered the mainline, be it a merge-commit or a regular commit, the mismatch alert should not happen.