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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> - 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.

;-)

>> - 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.

I don't understand the "when ..." qualification, since my suggestion is
only meaningful in that precise case.  As for the inefficiency: as long
as the upstream is not enormous and that we don't have too many packages
following that model, it's bearable.

> 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

No subtree: I really mean the whole Git branch being duplicated
will-nilly for each subpackage.

>> - 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.
>> - split the upstream repository.
> Not my call to make.

Of course it can also be a mix of the two and it can be done in bits and
pieces: every bit helps.  So maybe we can start by lobbying the upstream
for one specific subpackage we identified as being a good candidate for
either a separate upstream repository or for having the subpackage be
merged with another.

>>   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 know what you mean: that's exactly why the new code goes to the
trouble of checking the commit that modified the `Version:` line.
It's all too common for me to want to bump the version right before
installing experimental new code.

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

Fetching tags from upstream is problematic (because we have a single
elpa.git repository for all packages), but we could use tags manually
pushed to elpa.git, yes.


        Stefan