Re: Reconsider defaults for use-package-vc-prefer-newest

[Eli Zaretskii <eliz@gnu.org>]

> From: Charles Choi <kickingvegas@gmail.com>
> Date: Thu, 26 Sep 2024 16:23:22 -0700
> Cc: Philip Kaludercic <philipk@posteo.net>,
>  Martin Edström <meedstrom@runbox.eu>,
>  Tony Zorman <tonyzorman@mailbox.org>
> 
> 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.