[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Supporting multiline Package-Requires header

From: Achim Gratz
Subject: Re: Supporting multiline Package-Requires header
Date: Sun, 23 Aug 2015 08:33:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Stefan Monnier writes:
>>     (or (lm-header "package-version")
>>         (lm-header "version")
>>         (unless (equal pkg "org")
>>           (error "Missing `version' header")))
>> Is this still necessary?

I've finally had a look at what you're doing there.

> Sadly, yes.  But it should be "easy" to solve: ask the Org guys to put the
> version of their package in org.el's pseudo-headers.

The easy solution is to recognize that you already got a complete
package archive from the Org guys which is ready to be deployed.

> I put quotes around "easy" because they have a latent problem with their
> version numbers.

No, it's actually your expectation to have version numbers in the
comments of a non-generated, version-controlled file that's a latent
problem.  Keeping that up-to-date would require a stream of otherwise
useless commits in the VCS and result in merge conflicts while keeping
the maint and master branch in sync.  It may be sort of OK for simple
packages, but for anything else it isn't.

The only problem we have with the version numbers has been forced by an
external package archive we have no control over and that never even put
out a correctly packaged Org that would actually work when installed.
But their versioning scheme has been org-YYYYMMDD.  We'd totally switch
to something like 8.3.1-56-g17a225-elpa if there was a way to make sure
that the existing versioning scheme wouldn't get people stuck on
outdated releases.

Now, if you still insist on having these headers, the easiest way is to
put them into org-version.el since that file is already generated.  But
you'd have to look there in preference of the "main" package file if it
exists.  I don't want to modify org.el just for ELPA and re-organizing
the sources so that org.el becomes a generated file instead is possible,
but not really something we'd normally do on the maint branch.

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]