* bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)
2021-08-04 0:39 ` Phil Sainty
@ 2021-08-04 0:59 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-04 3:23 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-04 8:10 ` Lars Ingebrigtsen
2 siblings, 0 replies; 12+ messages in thread
From: Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-08-04 0:59 UTC (permalink / raw)
To: Phil Sainty; +Cc: 49855, monnier
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)
2021-08-04 0:39 ` Phil Sainty
2021-08-04 0:59 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-08-04 3:23 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-04 8:10 ` Lars Ingebrigtsen
2 siblings, 0 replies; 12+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-08-04 3:23 UTC (permalink / raw)
To: Phil Sainty; +Cc: 49855
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)
2021-08-04 0:39 ` Phil Sainty
2021-08-04 0:59 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-04 3:23 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-08-04 8:10 ` Lars Ingebrigtsen
2021-08-04 12:31 ` Phil Sainty
2 siblings, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-04 8:10 UTC (permalink / raw)
To: Phil Sainty; +Cc: 49855, monnier
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)
2021-08-04 8:10 ` Lars Ingebrigtsen
@ 2021-08-04 12:31 ` Phil Sainty
2021-08-04 22:24 ` Phil Sainty
2021-08-04 22:33 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 12+ messages in thread
From: Phil Sainty @ 2021-08-04 12:31 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 49855, monnier
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)
2021-08-04 12:31 ` Phil Sainty
@ 2021-08-04 22:24 ` Phil Sainty
2021-08-04 22:33 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 12+ messages in thread
From: Phil Sainty @ 2021-08-04 22:24 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 49855, monnier
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 :)
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)
2021-08-04 12:31 ` Phil Sainty
2021-08-04 22:24 ` Phil Sainty
@ 2021-08-04 22:33 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-05 13:11 ` Phil Sainty
1 sibling, 1 reply; 12+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-08-04 22:33 UTC (permalink / raw)
To: Phil Sainty; +Cc: Lars Ingebrigtsen, 49855
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)
2021-08-04 22:33 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-08-05 13:11 ` Phil Sainty
2021-08-05 14:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 12+ messages in thread
From: Phil Sainty @ 2021-08-05 13:11 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Lars Ingebrigtsen, 49855
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
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)
2021-08-05 13:11 ` Phil Sainty
@ 2021-08-05 14:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-22 11:07 ` Lars Ingebrigtsen
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-08-05 14:32 UTC (permalink / raw)
To: Phil Sainty; +Cc: Lars Ingebrigtsen, 49855
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread