Howdy,
I don't see why we want to change tag format (!) on existing,
especially long time existing and running projects.
What gain does it give ASIDE for some tooling nicer output, that we
never used before (that generates something out of it)?
How to sort history after? How to process tags for some automation
when it changes in the middle?
I am really against doing this "right in the middle".
Changing tag format on brand new projects makes sense to me (before
the first tag is done),
but doing it "as we go"?
As for GH release notes I always _remove_ the prefix (ie. tag is
foo-3.4.1 then release title is 3.4.1, same as project.version).
Having this "v${project.version}" ONLY to spare for this string op is
-1 for me, plus it most probably breaks git automatic processing as
well, no?
On Thu, May 1, 2025 at 10:30 PM Slawomir Jaranowski
<s.jaranow...@gmail.com> wrote:
>
> Hi,
>
> We introduce a short and the same template release tag name for Maven
> projects as:
>
> v@{project.version}
>
> in parent 44: https://github.com/apache/maven-parent/pull/455
>
> It will change a tag name on history ... but for me is more modern and
> simplified other configurations like for release-drafter
>
> It is also used in GitHub to point release notes, eg
>
> old tga format
> https://github.com/apache/maven-clean-plugin/releases/tag/maven-clean-plugin-3.4.1
>
> new tag format:
> https://github.com/apache/maven-parent/releases/tag/v44
>
> so we don't have a duplicate component name in the path.
>
>
> Any objections for the new tag format ...?
>
> --
> Sławomir Jaranowski
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
