From: "Bozhidar Batsov" <bozhidar@batsov.dev>
To: "Emacs Devel" <emacs-devel@gnu.org>
Subject: Re: Don't add tags to ELPA packages -- documentation?
Date: Wed, 18 Aug 2021 09:41:37 +0300 [thread overview]
Message-ID: <83e594e7-e7b1-455d-807c-2b3020abdf4a@www.fastmail.com> (raw)
In-Reply-To: <9f29e7dafac0498cffad17b4db809445@webmail.orcon.net.nz>
[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]
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. Does it sync the tags from the remotes or what?
In general I don't think that something like "stop tagging your releases upstream" is a good solution. Adding a prefix to the tag name (e.g. the package name) also seems weird in the context of a single project repository.
On Wed, Aug 18, 2021, at 5:30 AM, Phil Sainty wrote:
> On 2021-08-18 11:36, Eric Abrahamsen wrote:
> > Okay, this is really useful! Thank you. So it's only an issue if
> > package
> > maintainers have explicitly pushed their tags to the ELPA repo. So all
> > the README needs to say, really, is "don't push your tags to the ELPA
> > repo".
>
> Yes, I think so; although it might be worthwhile elaborating to avoid
> any potential confusion. Something like:
>
> Git tags should not be pushed to the ELPA repository. This is because:
>
> * Tags are global throughout any git repository.
>
> * Therefore tags sourced from one package might conflict with tags
> sourced from another project (e.g. a version tag "1.0").
>
> * The ELPA repository doesn't need any tags.
>
> Note that git will not push any tags unless you explicitly tell it to
> do so.
>
>
>
[-- Attachment #2: Type: text/html, Size: 2061 bytes --]
next prev parent reply other threads:[~2021-08-18 6:41 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 [this message]
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
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
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=83e594e7-e7b1-455d-807c-2b3020abdf4a@www.fastmail.com \
--to=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 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).