unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Jonas Bernoulli <jonas@bernoul.li>
To: 53221@debbugs.gnu.org
Cc: Stefan Kangas <stefan@marxist.se>
Subject: bug#53221: Keeping Version header and tag in sync
Date: Wed, 12 Jan 2022 19:34:06 +0100	[thread overview]
Message-ID: <8735lspzvl.fsf@bernoul.li> (raw)

Hello,

I have brought this up elsewhere and Stefan Kangas asked me to repeat it
here so we don't forget about it.

1: https://github.com/magit/orgit/pull/45

[Non]GNU Elpa uses the [Package-]Version header to determine a package's
version, while Melpa Stable uses the latest Git/Hg version tag.  (Let's
not talk about what Melpa "bleeding edge" does.)

It is desirable that these package archives as well as other tools that
use either one of these techniques agree which commit a version string
refers too.

To accomplish this we have to bump the version in both locations at the
same time.  At the exact same time!  One should not bump the Version
header in one commit, add a few more commits, and then tag the latest
commit with the same version as was first used in the library header a
few commits earlier.

We are stuck with two sources for the same information and we should try
hard to keep these two sources in agreement.  This also means that when
we invite new packages into [Non]GNU Elpa and instruct their maintainers
to add the Version header, that we then also make them aware of this
complication.

IMO this is how it should be done given the current schism:

1. Update the `Version` header keyword.
2. Possibly make other release-related changes like updating the
   `NEWS` file or updating the version in manuals and such.
3. Create a commit with a message like "Release version VERSION",
   where VERSION is exactly the same version as used in the header.
4. Tag that commit using the same version as used in the header and
   commit message (optionally prefixed with `v` because that is the
   Git convention).  Ideally the tag is signed and annotated.  If it
   is annotated, then it should use a message like "Release version
   VERSION" or "PACKAGE-NAME VERSION".
5. When pushing the release commit, then don't forget to push the
   release tag as well.

Obviously it would be nice to say the above with less words. ;)

     Jonas





                 reply	other threads:[~2022-01-12 18:34 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735lspzvl.fsf@bernoul.li \
    --to=jonas@bernoul.li \
    --cc=53221@debbugs.gnu.org \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).