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

Previous Next

Full log

Message #11 received at 49855 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 49855 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#49855: Problem with GNU ELPA build of :core package (Re:
 [GNU ELPA] So-Long version 1.1)
Date: Wed, 04 Aug 2021 01:59:23 +0100

Phil Sainty <psainty <at> 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

Previous Next

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