M-x add-release-logs

M-x add-release-logs

[Glenn Morris]

add-release-logs in admin.el adds "Version X.Y released" to every single
ChangeLog in Emacs (except the one in lisp/gnus, I imagine due to
hysterical raisins that have not been carried over to Cedet, Org, etc).
There are quite a few ChangeLogs now. Doing this seems a bit of pain.
IMO, it would be simpler to just put it in the top-level ChangeLog.
Any objections?

(This information is less useful than it was, due to branching.
"Version 24.2 released" does not appear anywhere in the current emacs-24
ChangeLogs, for example, because that release came from a different
branch. There is no point in the emacs-24 ChangeLogs that corresponds to
24.2.)

M-x add-release-logs

[Stephen J. Turnbull]

Glenn Morris writes:

 > Doing this seems a bit of pain.

My release script does it automatically, and also makes a commit with
that herald as its log.

 > IMO, it would be simpler to just put it in the top-level ChangeLog.
 > Any objections?

I do find both the commit herald and the ChangeLog entry useful, even
on a relatively short branch.  Not an objection, just an observation.

Re: M-x add-release-logs

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 08 Mar 2013 04:15:11 -0500
> 
> 
> add-release-logs in admin.el adds "Version X.Y released" to every single
> ChangeLog in Emacs (except the one in lisp/gnus, I imagine due to
> hysterical raisins that have not been carried over to Cedet, Org, etc).
> There are quite a few ChangeLogs now. Doing this seems a bit of pain.
> IMO, it would be simpler to just put it in the top-level ChangeLog.
> Any objections?

How would I know then, by looking just at the release tarball, what
was the latest change that went into a particular file?  I'd have to
go to the repository, no?

> (This information is less useful than it was, due to branching.
> "Version 24.2 released" does not appear anywhere in the current emacs-24
> ChangeLogs, for example, because that release came from a different
> branch. There is no point in the emacs-24 ChangeLogs that corresponds to
> 24.2.)

That's actually a Bad Thing, IMO.  But at least we have that on all
releases made from the same branch.

Re: M-x add-release-logs

[Glenn Morris]

Eli Zaretskii wrote:

>> IMO, it would be simpler to just put it in the top-level ChangeLog.
>> Any objections?
>
> How would I know then, by looking just at the release tarball, what
> was the latest change that went into a particular file?

Err, by looking in the relevant ChangeLog?
I don't understand your question.

Re: M-x add-release-logs

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 08 Mar 2013 11:57:06 -0500
> 
> Eli Zaretskii wrote:
> 
> >> IMO, it would be simpler to just put it in the top-level ChangeLog.
> >> Any objections?
> >
> > How would I know then, by looking just at the release tarball, what
> > was the latest change that went into a particular file?
> 
> Err, by looking in the relevant ChangeLog?

If the relevant ChangeLog doesn't have the "Emacs XX.YY released"
entry, how it will help me?

Or maybe I don't understand your answer.

Re: M-x add-release-logs

[Glenn Morris]

Eli Zaretskii wrote:

> If the relevant ChangeLog doesn't have the "Emacs XX.YY released"
> entry, how it will help me?

I assumed you meant the most recent change to a file in that particular
release, which is obviously just whatever the most recent entry is.

If you meant "if I have the Emacs 24.7 tarfile, and want to know what
the last change to subdir/foo.el was in Emacs 24.1, without either the
24.1 tarfile or a copy of the repository", then first you would have to
hope that 24.7 and 24.1 came from the same branch, and then you would
just look at the top-level ChangeLog (rather than subdir/ChangeLog) in
24.7 to get the release date for 24.1.

Re: M-x add-release-logs

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 08 Mar 2013 14:08:33 -0500
> 
> If you meant "if I have the Emacs 24.7 tarfile, and want to know what
> the last change to subdir/foo.el was in Emacs 24.1, without either the
> 24.1 tarfile or a copy of the repository"

Yes, that's what I meant.

> then first you would have to hope that 24.7 and 24.1 came from the
> same branch

They usually do.

> and then you would just look at the top-level ChangeLog (rather than
> subdir/ChangeLog) in 24.7 to get the release date for 24.1.

Date granularity is not fine enough to tell what was the last change,
not in busy directories like src and lisp.

Re: M-x add-release-logs

[Glenn Morris]

Eli Zaretskii wrote:

> Date granularity is not fine enough to tell what was the last change,
> not in busy directories like src and lisp.

No directory is busy around release time.

There will never (...) be a release where code changes happened on the
same day as the release.

Re: M-x add-release-logs

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 08 Mar 2013 14:56:54 -0500
> 
> Eli Zaretskii wrote:
> 
> > Date granularity is not fine enough to tell what was the last change,
> > not in busy directories like src and lisp.
> 
> No directory is busy around release time.

Theoretically, yes.  But not in my experience.  Last-minute changes
are actually quite frequent.

> There will never (...) be a release where code changes happened on the
> same day as the release.

Never say "never".  From emacs-23.1/src/ChangeLog:

  2009-07-29  Chong Yidong  <cyd@stupidchicken.com>

	  * Version 23.1 released.

  2009-07-29  Adrian Robert  <Adrian.B.Robert@gmail.com>

	  * nsfont.m (ns_findfonts): Fix 2009-07-24 change to return only one
	  element, not a list, for match case.

From emacs-23.3/lisp/ChangeLog:

  2011-03-07  Chong Yidong  <cyd@stupidchicken.com>

	  * Version 23.3 released.

  2011-03-07  Chong Yidong  <cyd@stupidchicken.com>

	  * progmodes/cc-cmds.el (c-beginning-of-statement): Fix 2011-01-31
	  change; patch supplied by Alan Mackenzie was applied incorrectly.

From emacs-24.1/lisp/ChangeLog:

  2012-06-01  Chong Yidong  <cyd@gnu.org>

	  * Version 24.1 released.

  2012-06-01  Glenn Morris  <rgm@gnu.org>

	  * mail/rmail.el (rmail-yank-current-message):
	  Leave point at correct position.  (Bug#11660)

  2012-06-01  Chong Yidong  <cyd@gnu.org>

	  * allout-widgets.el: Fix code header

From emacs-24.2/src/ChangeLog:

 2012-08-24  Chong Yidong  <cyd@gnu.org>

	 * Version 24.2 released.

 2012-08-24  Eli Zaretskii  <eliz@gnu.org>

	 * ralloc.c (free_bloc): Don't dereference a 'heap' structure if it
	 is not one of the heaps we manage.  (Bug#12242)

Re: M-x add-release-logs

[Glenn Morris]

Eli Zaretskii wrote:

> Never say "never".  From emacs-23.1/src/ChangeLog:

I'm simultaneously cheered and depressed by this information. :)

Anyway, you got me.

Re: M-x add-release-logs

[Stefan Monnier]

>> There will never (...) be a release where code changes happened on the
>> same day as the release.
> Never say "never".  From emacs-23.1/src/ChangeLog:

When trying to "reverse engineer" a CVS tag to represent "the files used
to build the tarball" of earlier Emacs versions (which I did for 19.34
and a few others) I found out that Eli is right.

Still, I don't think it's a big issue nowadays, so I think it's OK to
only add it to the top-level ChangeLog.  OTOH I do think that the commit
that added "Version 24.2 released" should be merged into the emacs-24
branch (and subsequently into the trunk) such that this tag appears in
all subsequent releases.


        Stefan

Re: M-x add-release-logs

[Xue Fuqiao]

On Fri, 08 Mar 2013 21:22:05 -0500
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I do think that the commit that added "Version 24.2 released" should
> be merged into the emacs-24 branch (and subsequently into the trunk)
> such that this tag appears in all subsequent releases.

+1

-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: M-x add-release-logs

[Paul Eggert]

On 03/08/2013 01:15 AM, Glenn Morris wrote:
> IMO, it would be simpler to just put it in the top-level ChangeLog.
> Any objections?

No, in fact I'd mildly prefer it that way.  One less thing to worry
about when merging.