ChangeLog API

ChangeLog API

[Edward Knyshov]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

Hello.

I just updated 60 elpa packages in my emacs setup and I have no idea what
changed and what happened to my environment now. I'd like to ask a dev
community, do we need a some kind of unified changelog api for emacs, so
each package would provide changes information for each new version via
this api. I see this feature as ability to read all the changes on all the
packages after I do such a big upgrade.

What do you think guys? Maybe there is already some functionality for this..

Thank you in advance, Edward.

[-- Attachment #2: Type: text/html, Size: 603 bytes --]

Re: ChangeLog API

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

>>>>> Edward Knyshov <edvorg@gmail.com> writes:

> I just updated 60 elpa packages in my emacs setup and I have no idea what
> changed and what happened to my environment now. I'd like to ask a dev
> community, do we need a some kind of unified changelog api for emacs, so
> each package would provide changes information for each new version via this
> api. I see this feature as ability to read all the changes on all the
> packages after I do such a big upgrade.

Even if we had such an API, enforcing it as a requirement for a package's
inclusion in GNU ELPA -- otherwise, most packages would probably ignore it --
would be rather heavy-weight. Further, the result would likely be a large
volume of information for you to ingest. I don't see the cost/benefit ratio
adding up for an API like this.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: ChangeLog API

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 3386 bytes --]

On 03/23/2016 02:34 PM, John Wiegley wrote:
>>>>>> Edward Knyshov <edvorg@gmail.com> writes:
>
> Even if we had such an API, enforcing it as a requirement for a package's
> inclusion in GNU ELPA -- otherwise, most packages would probably ignore it --
> would be rather heavy-weight. Further, the result would likely be a large
> volume of information for you to ingest. I don't see the cost/benefit ratio
> adding up for an API like this.

We already have a notion of per-file change logs, though:

    `;;; Change Log:'
         This begins change log information stored in the library file (if you store the change history there). For Lisp files distributed with Emacs, the change history is kept in the file `ChangeLog' and not in the source file at all; these files generally do not have a `;;; Change Log:' line. `History' is an alternative to `Change Log'.

Many packages are already using it (to some extent), but since it isn't really displayed anywhere there are little incentives to keep it up to date.

One common format seems to be

    ;; [date] [some sort of separator] [some message]

For example:

    (json.el)
    ;;; History:
    ;; 2006-03-11 - Initial version.
    ;; 2006-03-13 - Added JSON generation in addition to parsing. Various
    ;; other cleanups, bugfixes, and improvements.
    ;; 2006-12-29 - XEmacs support, from Aidan Kehoe <kehoea@parhasard.net>.
    ;; 2008-02-21 - Installed in GNU Emacs.
    ;; 2011-10-17 - Patch `json-alist-p' and `json-plist-p' to avoid recursion -tzz
    ;; 2012-10-25 - Added pretty-printed reformatting -Ryan Crum (ryan@ryancrum.org)

    (rfc2104.el)
    ;;; History:
    ;; (...)
    ;; 2000-05-12 added sha-1 example, added test case reference
    ;; 2003-11-13 change rfc2104-hexstring-to-bitstring to ...-byte-list
    ;; 2008-04-25 rewrite rfc2104-hash for speed

    (company-coq.el)
    ;;; History:
    ;; 2016-02-28 — Show input hints for Unicode and prettified symbols
    ;; 2016-02-28 — Prettify symbols in notation strings and code blocks
    ;; 2016-02-07 — Support for changing [Require]s to use fully qualified names
    ;; 2016-02-02 — Preserve names by inserting intros when extracting a lemma


That being said, some packages also put historical notes in there. Others use different conventions, such as the following

    (cl-lib.el)
    ;;; Change Log:
    ;; Version 2.02 (30 Jul 93):
    ;; * Added "cl-compat.el" file, extra compatibility with old package.
    ;; * Added `lexical-let' and `lexical-let*'.
    ;; * Added `define-modify-macro', `callf', and `callf2'.
    ;; * Added `ignore-errors'.

    (uniquify.el)
    ;;; Change Log:
    ;; Originally by Dick King <king@reasoning.com> 15 May 86
    ;; Converted for Emacs 18 by Stephen Gildea <gildea@stop.mail-abuse.org>
    ;; Make uniquify-min-dir-content 0 truly non-invasive. gildea 23 May 89
    ;; Some cleanup. uniquify-min-dir-content default 0. gildea 01 Jun 89

As a user, it would be nice to get a short summary of new features when I update; as a package maintainer, I'd love a way to show that information to users.
It could be through a unified NEWS file, too. And we could take a hands-off approach to it by displaying the information if we have it; then maybe users would push package maintainers to include that information, if they do want it.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ChangeLog API

[Stefan Monnier]

>> Even if we had such an API, enforcing it as a requirement for a package's
>> inclusion in GNU ELPA -- otherwise, most packages would probably ignore it --
>> would be rather heavy-weight. Further, the result would likely be a large
>> volume of information for you to ingest. I don't see the cost/benefit ratio
>> adding up for an API like this.
> We already have a notion of per-file change logs, though:

*GNU* ELPA packages include a ChangeLog that's auto-generated from the git
log, and is hence at a 100% standardized place.
So we could use that, to some extent.

The problem is that this is ChangeLog, whereas what the end user would
like to see, usually is a NEWS.

Still, we could add to package.el some function to try and extract the
ChangeLog from an installed package.  And then compare the ChangeLog
before upgrade to the ChangeLog after upgrade, to show the user
what's actually changed.

It would then be pretty easy to improve the code so that it uses a NEWS
section in preference to the ChangeLog section, when available.


        Stefan

Re: ChangeLog API

[raman]

The other piece that is already a valuable "user facing changes  tracker
" is the ability to specify when a user customizable option changed  by
adding the appropriate declarations in defcustom -- a feature that is
not as widely used  at present.
-- 

Re: ChangeLog API

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 221 bytes --]

On 03/24/2016 09:29 AM, Stefan Monnier wrote:
> It would then be pretty easy to improve the code so that it uses a NEWS
> section in preference to the ChangeLog section, when available.

Indeed, that would be nice


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]