[
https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651889#comment-17651889
]
Michael Osipov edited comment on MRELEASE-1073 at 12/25/22 10:44 PM:
---------------------------------------------------------------------
Looking back at the red/green/yellow listing your provided a branch must never
have a snapshot for a version which has already been released. At least one
components needs to be incremented.
I believe that the following approch works for you:
{noformat}
trunk (e.g., 1.x)
|- branch 1.0.x
|- branch 1.1.x
`- branch 1.2.x
{noformat}
All of them contain snapshots, of course. Now you can create branches from
these branches to please specific customers or customer-agnostic features which
are merged back into parent. Customer-specific branches (e.g., 1.0.x-edf) are
never merged back, but only receive global changes.
On which branch you use a pre-release qualifier it is upto you.
was (Author: michael-o):
Looking back at the red/green/yellow listing your provided a branch must never
have a snapshot for a version which has already been released. At least one
components needs to be incremented.
I believe that the following approch works for you:
trunk (e.g., 1.x)
|- branch 1.0.x
|- branch 1.1.x
`- branch 1.2.x
All of them contain snapshots, of course. Now you can create branches from
these branches to please specific customers or customer-agnostic features which
are merged back into parent. Customer-specific branches (e.g., 1.0.x-edf) are
never merged back, but only receive global changes.
On which branch you use a pre-release qualifier it is upto you.
> 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-22-54-58-570.png,
> image-2022-01-03-12-10-55-213.png, image-2022-01-03-12-13-06-345.png,
> image-2022-01-03-12-14-20-084.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.10#820010)
