guix-patches
[Top][All Lists]
Advanced

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

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


From: Sergiu Ivanov
Subject: [bug#59352] [PATCH] gnu: Add emacs-org-tree-slide.
Date: Sat, 19 Nov 2022 12:18:07 +0100
User-agent: mu4e 1.8.11; emacs 28.2

Hello,

Nicolas Goaziou <mail@nicolasgoaziou.fr> [2022-11-19T10:38:00+0100]:
> Hello,
>
> Sergiu Ivanov <sivanov@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





reply via email to

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