[MCHANGES-412] Allow an action to carry an optional scope

[jira-importer]

Gary D. Gregory opened MCHANGES-412 and commented

In changes.xml, I would like an action to carry an optional {}scope{}.

This would help users understand what changes affect which part of their projects.

For example:

<action issue="ABC-189" type="fix" {}scope="runtime"{}>Fix some bug</action>
<action issue="ABC-190" type="update" {}scope="test"{}>Bump dependency foo from 1 to 2</action>
<action issue="ABC-191" type="update" {}scope="build"{}>Bump commons-parent foo from 1 to 2</action>
<action issue="ABC-191" type="update" {}scope="site"{}>Documented this and that</action>

The use of the scope documents where the change applies, usually runtime, test, or build, but it could be string maybe.

This somewhat parallels the concept of a scope in a dependency so the value set could be the same as allowed for a dependency scope but that might be too restrictive.

Thoughts?

---

No further details from MCHANGES-412

[jira-importer]

Gary D. Gregory commented

Is this something I should bother creating a PR for or are you guys not interested?

[jira-importer]

Gary D. Gregory commented

Ping?

[jira-importer]

Elliotte Rusty Harold commented

Closing as too idiosyncratic. I don't think there's enough interest in this to justify the extra weight and maintenance burden.

[jira-importer]

Slawomir Jaranowski commented

Elliotte Rusty Harold, Gary Gregory  - I have no problem with next optional attribute 

It is some of idea which can be implemented by contributors.

So I will re-poen it.

[ppkarwasz]

If I find the time, I’d like to work on this and also explore a few related enhancements:

• Expand the list of change types: In the Log4j Changelog, we use a broader set of types:

  • removed for breaking changes,
  • added, changed, and deprecated for minor version-level changes (we’ve had several reports of users failing builds due to deprecations, so these likely deserve more visibility),
  • fixed for regular bug fixes,
  • updated specifically for dependency updates: these are usually just noise in the changelog.

• Add support for splitting changes.xml into multiple files to help reduce Git merge conflicts.

If no one else is planning to implement this in the near term, feel free to assign the issue to me. I’ll try to make time for it in the next couple of months.