From: Phil Sainty <psainty@orcon.net.nz>
To: Bozhidar Batsov <bozhidar@batsov.dev>
Cc: Emacs Devel <emacs-devel@gnu.org>
Subject: Re: Don't add tags to ELPA packages -- documentation?
Date: Wed, 18 Aug 2021 19:21:55 +1200 [thread overview]
Message-ID: <eed4a565c3b4f898a803d79fcd96b897@webmail.orcon.net.nz> (raw)
In-Reply-To: <83e594e7-e7b1-455d-807c-2b3020abdf4a@www.fastmail.com>
On 2021-08-18 18:41, Bozhidar Batsov wrote:
> I'm a bit confused by the conversation so far. Can someone elaborate
> on "maintainers have explicitly pushed their tags to the ELPA repo"?
> I do tag all the releases of my packages, as that's a common (and
> good) practice, but I don't understand why would something like this
> be affecting ELPA negatively.
It won't. Not unless you went out of your way to make it a problem.
Your "single project repository" is not the ELPA repo. The ELPA repo
contains all of the packages in that archive.
This whole discussion only applies if you are manually pushing code
changes to the ELPA repo. If your package is defined as an external
repo for ELPA's build processes to fetch automatically, then you aren't
pushing *anything* to the ELPA repo at all.
> Does it sync the tags from the remotes or what?
No, it doesn't, so tags can't be a problem if ELPA is fetching the
updates itself.
> In general I don't think that something like "stop tagging your
> releases upstream" is a good solution.
Keep tagging to your heart's content in your own repository. Just
don't push those tags to the ELPA repo (which you would need to do
explicitly with options to the "git push" command).
> Adding a prefix to the tag name (e.g. the package name) also seems
> weird in the context of a single project repository.
Again, this was purely in the context of the multi-project ELPA repo.
If someone particularly wanted tags in the ELPA repo for a package,
then the tags would need to be namespaced with a prefix in order to
avoid potential clashes.
-Phil
next prev parent reply other threads:[~2021-08-18 7:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-17 21:10 Don't add tags to ELPA packages -- documentation? Eric Abrahamsen
2021-08-17 21:24 ` Stefan Monnier
2021-08-17 21:51 ` Eric Abrahamsen
2021-08-17 22:01 ` Adam Porter
2021-08-17 22:51 ` Eric Abrahamsen
2021-08-17 23:04 ` Stefan Monnier
2021-08-17 23:15 ` Phil Sainty
2021-08-17 23:28 ` Phil Sainty
2021-08-17 23:36 ` Eric Abrahamsen
2021-08-18 2:30 ` Phil Sainty
2021-08-18 6:41 ` Bozhidar Batsov
2021-08-18 7:03 ` Yuan Fu
2021-08-18 13:25 ` Stefan Monnier
2021-08-18 13:31 ` Stefan Monnier
2021-08-18 14:26 ` Kévin Le Gouguec
2021-08-18 14:33 ` Stefan Monnier
2021-08-18 15:52 ` Eric Abrahamsen
2021-08-18 16:56 ` Eric Abrahamsen
2021-08-18 19:43 ` Kévin Le Gouguec
2021-08-18 23:07 ` Stefan Monnier
2021-08-19 20:54 ` Jonas Bernoulli
2021-08-19 23:38 ` Eric Abrahamsen
2021-08-20 7:11 ` Andreas Schwab
2021-08-20 15:59 ` Eric Abrahamsen
2021-08-19 23:44 ` Eric Abrahamsen
2021-08-18 7:21 ` Phil Sainty [this message]
2021-08-18 8:15 ` Bozhidar Batsov
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eed4a565c3b4f898a803d79fcd96b897@webmail.orcon.net.nz \
--to=psainty@orcon.net.nz \
--cc=bozhidar@batsov.dev \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.