unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Phil Sainty <psainty@orcon.net.nz>
To: 49855@debbugs.gnu.org
Cc: monnier@iro.umontreal.ca
Subject: bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)
Date: Wed, 04 Aug 2021 12:39:33 +1200	[thread overview]
Message-ID: <db34044390d56621d0ed43b6abd838c7@webmail.orcon.net.nz> (raw)
In-Reply-To: <2d94e1d983f91e0322747a86e7a6bcc9@webmail.orcon.net.nz>

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






  reply	other threads:[~2021-08-04  0:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <85czqu2qdw.fsf@elpa.gnu.org>
2021-08-04  0:17 ` bug#49855: Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1) Phil Sainty
2021-08-04  0:39   ` Phil Sainty [this message]
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
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
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
2022-08-22 11:24                 ` Phil Sainty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=db34044390d56621d0ed43b6abd838c7@webmail.orcon.net.nz \
    --to=psainty@orcon.net.nz \
    --cc=49855@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).