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

[Adam Porter <adam@alphapapa.net>]

> 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.
> 
> Just my 2¢.

This is described in the ELPA documentation.  See
<https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README> and
search for occurrences of "version".

The procedure I recommend, which you can see in the commit history of my 
ELPA packages is:

1. Configure the ELPA recipe to build from a "stable" release branch. 
Develop new versions on the master branch.

2. On master, make a new "Meta:" commit that updates the "Y" in the 
version header and adds a suffix, like "X.Y-pre" (e.g. "0.1-pre").

3. Develop the next version (the "Y" version, in SemVer terms) on master.

4. When that version is ready to release, make a new "Release:" commit 
that updates the version header, removing the suffix, to "X.Y" (e.g. "0.1").

5. Merge that commit into the "stable" branch, from which ELPA will build.

6. When ready to start developing the next version, goto 2.

7. To make a bug-fix release on a stable version, apply the same steps 
but on the stable branch (i.e. a "Meta:" commit setting the version 
header to "X.Y.Z-pre", then add commits fixing bugs, then a "Release:" 
commit setting the version header to "X.Y.Z"); then push the stable 
branch so ELPA will build it; and merge the stable branch into master to 
apply the bug fixes to master as appropriate.

This workflow is simple and only requires a few moments to update the 
version headers when needed.  It clearly separates commits that update 
source code from commits that update version information.  It ensures 
that only one commit (on each branch) has a version header with a 
certain version number (so there is no confusion about which commit with 
version X.Y a user actually has).  And it results in a simple commit 
graph.

YMMV, IWFM, etc.

--Adam