Some projects use git tag message to define its release notes, so they duplicate them on release node and git tag message.

Proposed resolution

To have an optional way for maintainers to activate a two flags:

  • One for retrieving the message and show it at release node creation.
  • Another for auto-publishing a release based on the last flag.

Remaining tasks

User interface changes

Two new options to be added on per-project basis.

API changes


Original report by wizonesolutions

As I was testing, I thought of something I hope is a neat idea.

If you pass the -a switch to git tag, you can enter a message that's as long as you like. Git resources often suggest using this to contain your release notes or something about what the tag means.

This could be useful metadata to d.o. How about pre-populating the release notes on step 2 of the "Add release" page with the git tag metadata?

So, for example, if I type

git tag -a 7.x-1.0
*** editor opens ***
Here are my release notes.
*** save and quit editor ***
git push --tags

then when I go to the Add release page and select 7.x-1.0 as the tag, on the subsequent screen I would Release notes populated with Here are my release notes. Of course, I'd be able to change that if I wanted, but it'd be handy

Let me know what you think!


franz’s picture

Following the current instructions, which are different for creating tags/releases, there is no input for such message, although it could be a nice idea.

wizonesolutions’s picture

Ah yes. This would also need documentation. git tag will not prompt you for a note. git tag -a is required.

eliza411’s picture

Status: Active » Postponed
Issue tags: +git phase 3

This seems like a neat idea to me and perfect for consideration in phase 3, since the team can't respond to this in our last 14 days before launch.

Tagging Git Phase 3 so it will be on our plate to consider and prioritize, and marking postponed for now.

Thanks for the feedback!

Josh The Geek’s picture

eliza411’s picture

Since it's come up in conversation a couple of times recently:

The audience of release node text is specifically intended to be non-developers. Release node text is supposed to make recommendations whether it's appropriate to even be testing the release if you're not actively developing, etc. so copying a commit message into it actually works against its purpose.

wizonesolutions’s picture

Status: Postponed » Active

Yeah, I know what you mean, but I was talking about the text that can be entered if you use the -a switch with git tag, which is not intended to be a commit message. Apparently, some people actually use that for release notes. That's why I suggested it. People can control what goes in there and make it non-developer-friendly. Hope that's clearer.

Niklas Fiekas’s picture

Assigned: Unassigned » Niklas Fiekas

That would be useful. I have a basic idea how to implement this - I'll try to reach out for sdboyer to discuss this with him to get it going.

Niklas Fiekas’s picture

anarcat’s picture

Title: Pre-populate release nodes with tag message from corresponding Git tag » Publish release nodes with tag message from corresponding Git tag

I would go even further: just create the release nodes with the tag message, *if present*. That would make releases so much easier, especially for multi-module distributions like openatrium.

In fact, i would even go as far as saying this is not really useful *unless* the release nodes are automatically created.

Since they would be created only if the tags were annoted, this wouldn't disrupt the current workflow... Plus releases would be created only if tags respected the naming convention so arbitrary non-release (but annoted) tags could still be pushed.

anarcat’s picture

Anyone working on this these days?

Niklas Fiekas’s picture

Assigned: Niklas Fiekas » Unassigned

I've not been doing anything here for a while. Unassigning for now.

anarcat’s picture

For those wanting something in between, is an option.

dww’s picture

Issue tags: -metadata, -stable releases

-1 on creating the release node itself automatically from annotated tags. For one thing, there'd be no way to properly configure the Release type taxonomy terms for the release node in that case (e.g. for security releases).

But I wouldn't mind pre-populated the release notes field from an annotated tag if it exists. I haven't looked closely at all that code to know exactly where such logic would live, probably in versioncontrol_project_git from versioncontrol_project since annotated tags are presumably completely specific to Git...

dww’s picture

p.s. I hate comment_alter_taxonomy and D6 issue tags. :/ WTF was that about? I didn't touch the tags at all... please re-tag if those are relevant to something. Sorry.

Niklas Fiekas’s picture

Yes. Pre-populating the node body was exactly the idea, if I remember correctly.

dww’s picture

Correct. I was replying to the change in scope proposed at #9.

anarcat’s picture

I would prefer to create those release nodes automatically. We can always go back and edit them to change the taxonomy type.

ergonlogic’s picture

+1 for for automatic release node creation. Prepopulating isn't saving much effort, when half of that is just a copy paste from 'drush rn'. A bunch of clicking around in d.o could be avoided though, and just done directly in git. That would be lovely!

ergonlogic’s picture

Issue summary: View changes

Make an initila issue summary with a proposal