bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

[Phil Sainty]

Yesterday I merged[1] so-long v1.1 to the Emacs master branch, and
per the GNU ELPA config[2] I subsequently got a notification email
to say that v1.1 was now on ELPA too; but I've noticed that the
ELPA version is wrong -- the tar file provided at the ELPA page[3]
does not contain the same version that is in Emacs.

It looks like it's taken one of the new commits and made a build
from that, but it's not the revision from the merge, so it's
missing many of the changes.

[1] 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3a56d4eea93e2fe832021a0685e2d9fe5bbd034b
[2] 
https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages?id=06e26055b3377#n346
[3] https://elpa.gnu.org/packages/so-long.html

Could someone (Stefan?) fix the ELPA version, and see if you can
figure out what went awry here?

I suppose the version may need a bump in case anyone has installed
this already.  Preferably something like 1.1.1 rather than 1.2.


-Phil


On 2021-08-04 09:02, ELPA update wrote:
> Version 1.1 of package So-Long has just been released in GNU ELPA.
> You can now find it in M-x package-list RET.
> 
> So-Long describes itself as:
>   Say farewell to performance problems with minified code.
> 
> More at https://elpa.gnu.org/packages/so-long.html

bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

[Phil Sainty]

On 2021-08-04 12:17, Phil Sainty wrote:
> Could someone (Stefan?) fix the ELPA version, and see if you can
> figure out what went awry here?

I now see that it specifically used the commit in which the
version number changed, and ignored everything which followed,
so I understand what happened now.

That didn't gel very well with my workflow (which was to bump
the version before adding new functionality, and then add the
new features (associating each one with the new version as I
went), and finally merge the branch for the completed release).

I'm not sure if ELPA could be made to recognise that scenario,
or if I'll need to ensure that the final commit always includes
a version bump.

I do understand that it's useful to be able to push changes
without changing the version on ELPA, so that you only create
a new release at the time you intend to, so I'm not asking for
every commit to create a new build; just wondering whether it's
possible to account for the branch merge scenario, where the
merge commit was intended to be the version bump commit.

In the meantime I guess I should commit this change to the
Emacs master branch?

-;; Version: 1.1
+;; Version: 1.1.1


-Phil

bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Phil Sainty <psainty@orcon.net.nz> writes:

> On 2021-08-04 12:17, Phil Sainty wrote:
>> Could someone (Stefan?) fix the ELPA version, and see if you can
>> figure out what went awry here?
>
> I now see that it specifically used the commit in which the
> version number changed, and ignored everything which followed,
> so I understand what happened now.
>
> That didn't gel very well with my workflow (which was to bump
> the version before adding new functionality, and then add the
> new features (associating each one with the new version as I
> went), and finally merge the branch for the completed release).
>
> I'm not sure if ELPA could be made to recognise that scenario,
> or if I'll need to ensure that the final commit always includes
> a version bump.
>
> I do understand that it's useful to be able to push changes
> without changing the version on ELPA, so that you only create
> a new release at the time you intend to, so I'm not asking for
> every commit to create a new build; just wondering whether it's
> possible to account for the branch merge scenario, where the
> merge commit was intended to be the version bump commit.

IIUC, something similar was brought up earlier this year:
https://lists.gnu.org/r/emacs-devel/2021-03/msg00490.html

Thanks,

-- 
Basil

bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> That didn't gel very well with my workflow (which was to bump
> the version before adding new functionality, and then add the
> new features (associating each one with the new version as I
> went), and finally merge the branch for the completed release).

What I can suggest in that case is to do:

1- bump the version from `AA.BB` to `CC.DD-git`
2- hack hack hack
3- when done, bump the version from `CC.DD-git` to `CC.DD`


        Stefan

bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

[Lars Ingebrigtsen]

Phil Sainty <psainty@orcon.net.nz> writes:

> I do understand that it's useful to be able to push changes
> without changing the version on ELPA, so that you only create
> a new release at the time you intend to, so I'm not asking for
> every commit to create a new build; just wondering whether it's
> possible to account for the branch merge scenario, where the
> merge commit was intended to be the version bump commit.

I don't really think there's any way to determine the intention here.
The developer may be working in a branch, fix something, bump the
number, fix some more (but doesn't want that to land in ELPA yet), and
then merge, for instance.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

[Phil Sainty]

On 2021-08-04 20:10, Lars Ingebrigtsen wrote:
> I don't really think there's any way to determine the intention here.
> The developer may be working in a branch, fix something, bump the
> number, fix some more (but doesn't want that to land in ELPA yet), and
> then merge, for instance.

I guess so.  It seems a less-likely workflow to my mind, but that may
just be my own habits and biases talking.

Still, it would be good if we could at least reduce the chances of 
people
getting tripped up by this.  Taking a different tack, perhaps we just 
need
a more detailed (or an additional) notification email.

At present I'm sent this:

> Subject: [GNU ELPA] So-Long version 1.1.1
> From: ELPA update <do.not.reply@elpa.gnu.org>
> To: gnu-emacs-sources@gnu.org
> Cc: Phil Sainty <psainty@orcon.net.nz>
> Reply-To: help-gnu-emacs@gnu.org
> 
> Version 1.1.1 of package So-Long has just been released in GNU ELPA.
> You can now find it in M-x package-list RET.
> 
> So-Long describes itself as:
>   Say farewell to performance problems with minified code.
> 
> More at https://elpa.gnu.org/packages/so-long.html


If in addition to that information, it also showed the commit hash and
message which was used to build the release, I would have immediately
seen that I'd messed up.  Something like:

> Build details:
> Commit 359a8e4eda047b7dcb7e64faff7f8eaacf5d937c
> ; * lisp/so-long.el: Bump to version 1.1

I'm not sure whether it's appropriate to include such details in that
particular notification, or if it would be better to send a separate
message to the maintainer; but either way these details would provide
direct confirmation as to whether the thing you thought had happened
had actually happened.

As it was, I thought I'd released "version 1.1", and the notification
told me that I'd done exactly that, and so I was completely confident
that everything was correct until I found that it wasn't.  I suspect
that if I hadn't done a sanity-check then I might not realised anything
was wrong until someone else told me.


-Phil

bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

[Phil Sainty]

On 2021-08-05 00:31, Phil Sainty wrote:
> At present I'm sent this:
>> Subject: [GNU ELPA] So-Long version 1.1.1

Please pretend that I'd shown the 1.1 notification message there,
rather than 1.1.1, so that the rest of that email makes better sense :)

bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> If in addition to that information, it also showed the commit hash and
> message which was used to build the release, I would have immediately
> seen that I'd messed up.  Something like:
>
>> Build details:
>> Commit 359a8e4eda047b7dcb7e64faff7f8eaacf5d937c
>> ; * lisp/so-long.el: Bump to version 1.1

Makes sense and sounds good.

> I'm not sure whether it's appropriate to include such details in that
> particular notification, or if it would be better to send a separate
> message to the maintainer;

I think we can keep it as a single message.
We could add something giving the commit id, the date of the commit
(personally, commit ids don't speak to me, but the commit date
might tip me off), and the first line of the commit message.
Seems short enough that it can fit before the NEWS without bothering
those readers who don't care about it.

Do you think you can come up with a patch against `elpa-admin.el`
doing that?


        Stefan

bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

[Phil Sainty]

On 2021-08-05 10:33, Stefan Monnier wrote:
> Do you think you can come up with a patch against `elpa-admin.el`
> doing that?

Yes, I think I can take a stab at that.

My initial foray has raised one item of potential interest:

Git 2.22 Release Notes
======================
  * "git log -L<from>,<to>:<path>" with "-s" did not suppress the patch
    output as it should.  This has been corrected.
    (merge 05314efaea jk/line-log-with-patch later to maint).

I don't know whether there's any reason to support older git
versions, but I'm using git 2.17.1 and so the command generated
by `elpaa--get-release-revision' gives me this:

$ git log -n1 --no-patch --pretty=format:%H -L '/^;;* 
*\(Package-\)\?Version:/,+1:lisp/so-long.el'
b84986af52d4e9debace2850a5ec106f51e38e61
diff --git a/lisp/so-long.el b/lisp/so-long.el
--- a/lisp/so-long.el
+++ b/lisp/so-long.el
@@ -11,1 +11,1 @@
-;; Version: 1.1
+;; Version: 1.1.1

I didn't twig initially that I wasn't seeing the intended
output, and spent a while fruitlessly wondering where in the
elisp that got trimmed down to a single line...


-Phil

bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Git 2.22 Release Notes
> ======================
>  * "git log -L<from>,<to>:<path>" with "-s" did not suppress the patch
>    output as it should.  This has been corrected.
>    (merge 05314efaea jk/line-log-with-patch later to maint).
>
> I don't know whether there's any reason to support older git
> versions, but I'm using git 2.17.1 and so the command generated
> by `elpaa--get-release-revision' gives me this:
>
> $ git log -n1 --no-patch --pretty=format:%H -L '/^;;*
> *\(Package-\)\?Version:/,+1:lisp/so-long.el'
> b84986af52d4e9debace2850a5ec106f51e38e61
> diff --git a/lisp/so-long.el b/lisp/so-long.el
> --- a/lisp/so-long.el
> +++ b/lisp/so-long.el
> @@ -11,1 +11,1 @@
> -;; Version: 1.1
> +;; Version: 1.1.1
>
> I didn't twig initially that I wasn't seeing the intended
> output, and spent a while fruitlessly wondering where in the
> elisp that got trimmed down to a single line...

Interesting.  `elpa.gnu.org` is running a more recent version of Git
because the older Git crashed in this same `elpaa--get-release-revision`
in some cases :-(

Debian stable is still on Git-2.20 so it might be worth adding
a workaround in `elpaa--get-release-revision` (tho a new Debian release
is due any day now, IIUC).


        Stefan

bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Debian stable is still on Git-2.20 so it might be worth adding
> a workaround in `elpaa--get-release-revision` (tho a new Debian release
> is due any day now, IIUC).

This was a year ago, so perhaps the machine has been updated now?

Anyway -- Phil, did you get any further with the proposed changes to
elpa-admin.el?

bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

[Phil Sainty]

On 2022-08-22 23:07, Lars Ingebrigtsen wrote:
> Anyway -- Phil, did you get any further with the proposed changes
> to elpa-admin.el?

I have work-in-progress for that on this machine, yes.

I'll have to try to get back to it.