Re: [elpa] main 8f4cb59: * elpa-packages (counsel, ivy, swiper): Auto-sync.

[Basil L. Contovounesios]

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