GNU bug report logs - #59352
[PATCH] gnu: Add emacs-org-tree-slide.

Previous Next

Full log

Message #19 received at 59352-done <at> debbugs.gnu.org (full text, mbox):

From: Sergiu Ivanov <sivanov <at> colimite.fr>
To: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Cc: 59352-done <at> debbugs.gnu.org
Subject: Re: [bug#59352] [PATCH] gnu: Add emacs-org-tree-slide.
Date: Sat, 19 Nov 2022 12:18:07 +0100

Hello,

Nicolas Goaziou <mail <at> nicolasgoaziou.fr> [2022-11-19T10:38:00+0100]:
> Hello,
>
> Sergiu Ivanov <sivanov <at> colimite.fr> writes:
>
>> So, I decided to update the existing definition and improve it according
>> to your suggestions.  I attach the new patch.
>
> Great! I applied it with a minor twist explained below.

Great, thank you!

>> Subject: [PATCH] gnu: emacs-org-tree-slide: Update to 2.8.18.
>>
>> * gnu/packages/emacs-xyz.scm (emacs-org-tree-slide): Update to 2.8.18.
>
> You're updating to the latest commit, which is not exactly "2.8.18", to
> "2.8.18-0.d6529bc".

Oh, OK, thank you for the explanation!  I am consistently bad at getting
versioning right.

> Also, the commit message must include changes you made to synopsis and
> description, which could arguably have been done in a subsequent commit,
> but that's fine.

I hesitated about that.  I'll split the changes over two patches the
next time.

>> ---
>>  gnu/packages/emacs-xyz.scm | 16 ++++++++--------
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
>> index fe0d9f1dc9..f827107b29 100644
>> --- a/gnu/packages/emacs-xyz.scm
>> +++ b/gnu/packages/emacs-xyz.scm
>> @@ -18644,11 +18644,11 @@ (define-public emacs-kotlin-mode
>>        (license license:gpl3+))))
>>  
>>  (define-public emacs-org-tree-slide
>> -  (let ((commit "036a36eec1cf712d3db155572aed325daa372eb5")
>> -        (revision "2"))
>> +  (let ((commit "d6529bc2df727d09014e0e56abf4f15a8e8fc20f")
>> +        (revision "3"))
>
> The revision is reset to "0" since you bumped the base version. Revision
> is here to ensure monotonic growth between version bumps because commit
> hashes cannot ensure this. Therefore, it is only useful to increase the
> revision number within the same base version.

Oh, I see!  I read the docs of git-version to see what "revision" meant,
but I didn't get that revision should be reset to 0 when the base
version is changed.

Thank you for taking the time to review my patch and explain
the details!

-
Sergiu

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.