[
https://issues.apache.org/jira/browse/VELOCITY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18034850#comment-18034850
]
Claude Brisson commented on VELOCITY-990:
-----------------------------------------
> I am against any manual process or patching Maven Release because it is not
> broken, the process is broken
It's a question of perspective... Please see below.
> Use versions and versions are cheap, drop RC dance
We already had this discussion. Maven looks like the *only* apache project I
know which has those "phantom" versions corresponding to unaccepted RCs.
Versions are not "cheap", they are semantic, and meant in fine for the users,
you can consider that it's a purely cosmetic point if you wish but I think it
is important to have consecutive version numbers. Also, I'm considering that
naming anything which is not released without an -RCx is potentially dangerous.
So with me on board, we will keep the RC dance.
> Continue to use RC, when an RC is accepted reroll the vote for a non-RC
> version, perform the release and remove RC tags since they never went to
> Central or dist.
Be serious. One vote is enough, a second one would just be too much. On what do
you vote, exactly? Oh, the "--rc" has been removed from the scm tag, we're
gonna re-roll all the tests again and check all the signatures again just for
that? Loose three days for that? Please respect out volunteering time.
So manual process it will be, just because there is no other viable alternative
as long as the maven team does not understand that an rc tag and a release tag
are not the same. We will vote with an scm tag in the pom which indicates what
*will* be the yet-non-existing tag of the release. I don't know why you have a
problem with that, it's plain logical and that's what plenty of other apache
projects are doing.
I co-authored with an AI a manual release script that you will find attached.
It still uses release:perform but not any more release:prepare as long as the
maven release plugin does not handle the scm tag correctly (aka does not
differentiate the RC tag and the final release tag).
> Releasing: make sure that scm/tag in pom.xml matches git tag
> ------------------------------------------------------------
>
> Key: VELOCITY-990
> URL: https://issues.apache.org/jira/browse/VELOCITY-990
> Project: Velocity
> Issue Type: Task
> Reporter: Peter Palaga
> Priority: Major
> Attachments: release.sh
>
>
> Hi, I noticed the following issue on recent releases that were preceded by
> RCs:
> The scm/tag is the RC version, not the actually released version that is
> present in <version> and that would match git tag.
> For example, for release 2.4.1, the tag and versions in pom.xml files are all
> {{2.4.1}}, but the scm/tag is
> {code:xml}
> <scm>
> ...
> <tag>2.4.1-rc1</tag>
> </scm>
> {code}
> Could you please adjust your processes next time, to make rebuilds easier?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
