all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org, Oleh Krehel <oleh@oremacs.com>
Subject: Re: [elpa] main 8f4cb59: * elpa-packages (counsel, ivy, swiper): Auto-sync.
Date: Wed, 10 Mar 2021 12:40:56 +0000	[thread overview]
Message-ID: <87eegn18rr.fsf@tcd.ie> (raw)
In-Reply-To: <jwvo8frx68h.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Tue, 09 Mar 2021 18:56:23 -0500")

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Suggestions:
>
> - change the versions after merging rather than before (as mentioned
>   above).  It's an easy low-tech solution, but it involves N times more
>   work if a single .git upstream version leads to N downstream releases.

O(2N) is still O(N) though, so not much worse than the status quo.  I've
gone with this for now so that the packages at least function properly.

[Hopefully this is the last version bump this month...]

> - if there's really only one version number shared by all the
>   sub-packages, I'd tend to argue that maybe there should only be one
>   package ;-)

I tend to agree ;).  Not my call to make, though, and that ship is
either getting smaller or sailing away.

> - as discussed earlier, we could have each subpackage have the complete
>   upstream Git and only create the subpackages via `elpa-package`
>   filtering out the other files.

That would be nice to have in general, but it doesn't solve the
inefficiency when multiple packages are bundled from the same repo.

Unless, of course, we either stop caring about the inefficiency (run out
of hair to pull?) or significantly complicate the Git dance, e.g.:
https://stackoverflow.com/q/600079/3084001

> - split the upstream repository.

Not my call to make.

> - add some other way than :version-map to specify which commit to use.
>   This could be a new :version-first-parent boolean option, or maybe

This would obviously "fix" part of my use-case, but I don't know how
good a solution it is.

>   a "don't look for commit in history" (after all, that's what the old
>   GNU ELPA script used to do: it used whichever commit was
>   HEAD when we discovered that the `Version:` "had changed" (meaning
>   the version in HEAD corresponds to not-yet-built file)).

The bump-after-merge works better for me personally, as I don't have to
worry about when to push which commits (I just have to repeat the same
dance 5 times, which at least is somewhat streamlined thanks to the
Project and Magit packages).

I guess another alternative to :version-map would be Git tags?
E.g. using an N.N.N-elpa scheme or something like that.

Thanks,

-- 
Basil



  reply	other threads:[~2021-03-10 12:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210225102521.11653.64611@vcs0.savannah.gnu.org>
     [not found] ` <20210225102523.7CEF420B28@vcs0.savannah.gnu.org>
2021-02-25 14:33   ` [elpa] main 8f4cb59: * elpa-packages (counsel, ivy, swiper): Auto-sync Basil L. Contovounesios
2021-02-25 15:12     ` Stefan Monnier
2021-02-25 16:24       ` Basil L. Contovounesios
2021-02-25 16:40         ` Stefan Monnier
2021-03-09 22:17         ` Basil L. Contovounesios
2021-03-09 23:56           ` Stefan Monnier
2021-03-10 12:40             ` Basil L. Contovounesios [this message]
2021-03-11 15:48               ` Stefan Monnier
2021-03-11 17:12                 ` Basil L. Contovounesios
2021-03-11 17:34                   ` Stefan Monnier
2021-03-11 19:25                     ` Basil L. Contovounesios
2021-03-11 22:47                       ` Stefan Monnier
2021-03-11 22:59                         ` Basil L. Contovounesios

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=87eegn18rr.fsf@tcd.ie \
    --to=contovob@tcd.ie \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=oleh@oremacs.com \
    /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.