[
https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467703#comment-17467703
]
Michael Osipov commented on MRELEASE-1073:
------------------------------------------
I don't see anything special is your diagram. Looks like a standard procedure
to work. Maven will properly recognize well known qualifiers liek alpha, beta,
etc. Additionally, Maven does not make a difference whether it is a GA version
or a prerelease. It will increment properly. Moving from 1.0-beta-1-SNAPSHOT
will move to 1.0-beta-1, then 1.0-beta-2-SNAPSHOT. At which point of the
release process is missing what you need? Have you considered a custom versoin
policy? We loosely support semantic versioning.
> Pre-Release generation
> ----------------------
>
> Key: MRELEASE-1073
> URL: https://issues.apache.org/jira/browse/MRELEASE-1073
> Project: Maven Release Plugin
> Issue Type: New Feature
> Reporter: Stéphane Passignat
> Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: image-2022-01-02-21-57-38-405.png
>
>
> Before generating a final release, it's often required to publish several
> kind of beta version. When one is validated, it's intended to become a pure
> release.
> SCM aspect:
> * create a tag
> * create a branch (option)
> Process impact:
> * be able to generate a release from a tag or revision
> * be able to generate a pre-release from a tag or revision
> Version number:
> * the version is calculated looking at the scm tags (ex: 1.0-SNAPSHOT become
> 1.0.beta14 if the tags matching the tag pattern have as higher number
> 1.0.beta13)
>
>
> There are maybe some discussion about the version number. Should it be .beta
> or -beta...
>
> I think it would be great to have this feature in the release plugin, keeping
> in one consistent tool all release facets.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
