version.h and ChangeLog

version.h and ChangeLog

[Bart Schaefer]

As we're no longer generating version.h from the revision tag in ChangeLog,
should we delete the last five lines of ChangeLog?

If the $"Revision: $" is still useful for some reason, we should at least
remove the text that says that ZSH_PATCHLEVEL is generated from that tag.

Re: version.h and ChangeLog

[Peter Stephenson]

On Sun, 07 Apr 2013 10:38:29 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> As we're no longer generating version.h from the revision tag in ChangeLog,
> should we delete the last five lines of ChangeLog?
> 
> If the $"Revision: $" is still useful for some reason, we should at least
> remove the text that says that ZSH_PATCHLEVEL is generated from that tag.

As far as I can see, it isn't and those lines should just go.

pws

Re: version.h and ChangeLog

[Bart Schaefer]

On Apr 7,  7:23pm, Peter Stephenson wrote:
}
} On Sun, 07 Apr 2013 10:38:29 -0700
} > If the $"Revision: $" is still useful for some reason, we should at least
} > remove the text that says that ZSH_PATCHLEVEL is generated from that tag.
} 
} As far as I can see, it isn't and those lines should just go.

OK ... so ... do we make a ChangeLog entry for changing the ChangeLog? :-)

Re: version.h and ChangeLog

[Frank Terbeck]

Peter Stephenson wrote:
> On Sun, 07 Apr 2013 10:38:29 -0700
> Bart Schaefer <schaefer@brasslantern.com> wrote:
>> As we're no longer generating version.h from the revision tag in ChangeLog,
>> should we delete the last five lines of ChangeLog?
>> 
>> If the $"Revision: $" is still useful for some reason, we should at least
>> remove the text that says that ZSH_PATCHLEVEL is generated from that tag.
>
> As far as I can see, it isn't and those lines should just go.

About $ZSH_PATCHLEVEL: Did someone try if the variable is handled/set
properly when building from a tarball, when "git describe" isn't
available - and if it was would throw an error?

If not, we should look at that so the next release will go smoothly.

Regards, Frank

Re: version.h and ChangeLog

[Peter Stephenson]

On Mon, 08 Apr 2013 14:30:12 +0200
Frank Terbeck <ft@bewatermyfriend.org> wrote:
> About $ZSH_PATCHLEVEL: Did someone try if the variable is handled/set
> properly when building from a tarball, when "git describe" isn't
> available - and if it was would throw an error?
> 
> If not, we should look at that so the next release will go smoothly.

I got patchlevel.h containing:

#define ZSH_PATCHLEVEL ""

which isn't particularly useful.

What should probably happen is that "make targz-src" should somehow
freeze the contents of patchlevel.h so that making it when untarred
doesn't update the header any further.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: version.h and ChangeLog

[Peter Stephenson]

On Mon, 8 Apr 2013 20:34:13 +0100
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> What should probably happen is that "make targz-src" should somehow
> freeze the contents of patchlevel.h so that making it when untarred
> doesn't update the header any further.

Here's one possible simple way of doing that, though it would be better
to move the code that generates the file contents into a script.

By the way, are we guaranteed that the output of 'git describe --tags
--long' is the same for everyone that has pulled the same code from the
server (and doesn't have local changes)?  If not, it would be worth a
bit of extra work to make it so: the whole point of the patchlevel is so
it consistently refers to a particular state of what's on the server for
reporting by users who are just tracking development.  Local changes are
really a special case here --- people developing the shell can be
assumed to be knowledgeable enough to make their own investigations ---
though if it's possible to indicate that there are changes not pushed to
the server in a way that sticks out, e.g. with something appended like
"-local-<ref>", that's useful, too.  This is definitely looking like a
script.

diff --git a/Makefile.in b/Makefile.in
index 5fb736f..a29ab78 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -160,6 +160,7 @@ targz-src: $(DISTNAME).tar.gz
 $(DISTNAME).tar.gz: FORCE
 	@$(sdir_top)/Util/mkdisttree.sh $(DISTNAME) $(sdir_top) $(dir_top) SRC \
 	    $(MAKE) $(MAKEDEFS)
+	echo '#define ZSH_PATCHLEVEL "'`git describe --tags --long`'"' >$(DISTNAME)/Src/patchlevel.h.release
 	tar cf - $(DISTNAME) | gzip -9 > $@
 	rm -rf $(DISTNAME)
 
diff --git a/Src/zsh.mdd b/Src/zsh.mdd
index 420e8fc..0fec5c3 100644
--- a/Src/zsh.mdd
+++ b/Src/zsh.mdd
@@ -40,8 +40,12 @@ version.h: $(sdir_top)/Config/version.mk zshcurses.h zshterm.h
 	echo '#define ZSH_VERSION "'$(VERSION)'"' > $@
 
 patchlevel.h: FORCE
-	echo '#define ZSH_PATCHLEVEL "'`git describe --tags --long`'"' > $@.tmp
-	cmp $@ $@.tmp && rm -f $@.tmp || mv $@.tmp $@
+	@if [ -f $(sdir)/$@.release ]; then \
+	  cp -f $(sdir)/$@.release $@; \
+	else \
+	  echo '#define ZSH_PATCHLEVEL "'`git describe --tags --long`'"' > $@.tmp; \
+	  cmp $@ $@.tmp && rm -f $@.tmp || mv $@.tmp $@; \
+	fi
 FORCE:
 
 zshcurses.h: ../config.h

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: version.h and ChangeLog

[Simon Ruderich]

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

On Mon, Apr 08, 2013 at 10:02:07PM +0100, Peter Stephenson wrote:
> By the way, are we guaranteed that the output of 'git describe --tags
> --long' is the same for everyone that has pulled the same code from the
> server (and doesn't have local changes)?  If not, it would be worth a
> bit of extra work to make it so: the whole point of the patchlevel is so
> it consistently refers to a particular state of what's on the server for
> reporting by users who are just tracking development.

Yes. git describe --tags --long uses the current commit and the
existing tags to create the string. If the user has the same
commit (e.g. by running git pull to get the latest changes) then
git describe will be the same.

>                                                        Local changes are
> really a special case here --- people developing the shell can be
> assumed to be knowledgeable enough to make their own investigations ---
> though if it's possible to indicate that there are changes not pushed to
> the server in a way that sticks out, e.g. with something appended like
> "-local-<ref>", that's useful, too.  This is definitely looking like a
> script.

Local commits aren't treated any different. But it's easy to
check because they don't exist in the official repository.

Consider this $ZSH_PATCHLEVEL: zsh-5.0.2-51-g9e7696a (the g means
Git and is not part of the sha1) which is from a local branch of
mine:

    $ git branch --contains 9e7696a 2>/dev/null
    $

And from an official commit, zsh-5.0.2-58-ge619a73:

    $ git branch --contains e619a73 2>/dev/null
    * master
    $

Appending something like "-local-<ref>" is difficult because
what's considered local depends on how Git is used. We could
check "origin"/master but what if I call the remote branch
"upstream"?

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

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

Re: version.h and ChangeLog

[Phil Pennock]

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

On 2013-04-09 at 18:47 +0200, Simon Ruderich wrote:
> Appending something like "-local-<ref>" is difficult because
> what's considered local depends on how Git is used. We could
> check "origin"/master but what if I call the remote branch
> "upstream"?

At some point, the onus of work shifts to the person who is violating
convention.  I mean, I might have used stty to remap intr to ^R.  Most
tools are entitled to assume that intr is ^C without bothering to check.
Still, robust tooling might support the unusual.

My normal approach here is to use a variable which can be overriden from
the environment:

  : ${ZSH_GIT_ORIGIN_REMOTENAME:=origin}

Then if someone really wants to work with a different name, for another
tooling environment, they can `export ZSH_GIT_ORIGIN_REMOTENAME=upstream`

A more git-like approach is be to stash the config in a zsh section of
the git config, so that it can be set on a per-repo basis or "globally"
if needed for an environment.  This might be more to taste, avoiding
25-character environment variable names?

% git config zsh.master origin
% git config --get-regexp zsh\..+
zsh.master origin
% git config --get zsh.master
origin
% tail -2 .git/config
[zsh]
	master = origin
%

Since this config is not sync'd from any remote, it's entirely available
for local overrides.

-Phil

[-- Attachment #2: Type: application/pgp-signature, Size: 163 bytes --]

Re: version.h and ChangeLog

[Simon Ruderich]

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

On Tue, Apr 09, 2013 at 04:18:52PM -0400, Phil Pennock wrote:
> On 2013-04-09 at 18:47 +0200, Simon Ruderich wrote:
>> Appending something like "-local-<ref>" is difficult because
>> what's considered local depends on how Git is used. We could
>> check "origin"/master but what if I call the remote branch
>> "upstream"?
>
> At some point, the onus of work shifts to the person who is violating
> convention.  I mean, I might have used stty to remap intr to ^R.  Most
> tools are entitled to assume that intr is ^C without bothering to check.
> Still, robust tooling might support the unusual.
>
> [snip]

Hello Phil,

Isn't that over-engineering for such a rarely relevant case? Most
people who use a Git checkout (should) understand that local
commits are not known to the rest of the world and that therefore
the `git describe` output is not meaningful in this case.

And everybody on the mailing list can use `git merge --contains`
to check if the reporter's Zsh is based on a public commit and if
not ask him to rebuild it.

I'd recommend that we keep it simple and extend it only if it's
really necessary.

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

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