[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[ https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651889#comment-17651889 ] Michael Osipov commented on MRELEASE-1073: -- 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)
[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[
https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468270#comment-17468270
]
Stéphane Passignat commented on MRELEASE-1073:
--
thanks for semver.org, as the plugin works regardless of the number of fields
composing the version number, I hope it won't be too strict.
Lets review the semantic.
# being able to add the initial patch field and a qualifier to the version
number, in the pom of the branch generated during the release process.
=> does this exist ?
"This works are you initially provided {{-beta-1}} qualifier."
No the trunk and maintenance branches don't have 'beta' qualifier, they have
SNAPSHOT qualifiers. Maybe the maintenance branch can have a beta qualifier,
but it's part of the previous topic.
Do you mean I need to fork the trunk, qualify it with beta, then to merge with
this branch to produce pre-releases ?
> 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.1#820001)
[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[
https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468187#comment-17468187
]
Michael Osipov commented on MRELEASE-1073:
--
bq. I want to make major releases from trunk, like 1.0, 1.1... for which the
corresponding SNAPSHOTS are 1.0-SNAPSHOT, 1.1-SNAPSHOT... and minor release
like 1.0.0, 1.0.1,
This is wrong. You are confusing what major and minor releases are. Please read
semver.org.
bq. being able to change the version in the maintenance branch, to the proper
minor version, during the release process.
This works
bq. being able to generate properly numbered "beta" version, which could maybe
be similar to the release process, but with 'beta' or'-beta' before the last
digit version.
This works are you initially provided {{-beta-1}} qualifier.
> 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.1#820001)
[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[ https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468169#comment-17468169 ] Stéphane Passignat commented on MRELEASE-1073: -- I think one or maybe two optional features could be great for this plugin. My initial post was maybe not clear enough, sorry about that, but now I think we're on the same page now. # being able to change the version in the maintenance branch, to the proper minor version, during the release process. # being able to generate properly numbered "beta" version, which could maybe be similar to the release process, but with 'beta' or'-beta' before the last digit version. So far I don't see where I'm wrong nor why these features would not be acceptable for the plugin. > 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.1#820001)
[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[ https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468139#comment-17468139 ] Michael Osipov commented on MRELEASE-1073: -- As far as I can see you are rather seeking for a consultant than a deficiency in this plugin. I recommend getting in touch with [~hboutemy]. > 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.1#820001)
[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[
https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468060#comment-17468060
]
Stéphane Passignat commented on MRELEASE-1073:
--
I want to make major releases from trunk things like 1.0, 1.1... for which the
corresponding SNAPSHOTS are 1.0-SNAPSHOT, 1.1-SNAPSHOT... and minor release
like 1.0.0, 1.0.1, ... the number of digit are not important to me, I just need
to have one more when I release a minor.
Anyway I tested the addition of a third digit, to be sure and I obtain exactly
the same behavior, which is fine. It just works as I expected with a proper
version generation.
So whatever the number of digits, the behavior is stable (which is very fine).
Let's look in details, I'm maybe wrong somewhere.
I added a third digit to the version and continue to use this command:
{{mvn --batch-mode release:clean release:prepare release:branch}}
(green: as I expected, red: things I really don't want, orange: cause of errors)
* Run#1 on trunk (release the 1.0.0 version)
** {color:#00875a}trunk version changes to 1.0.1-SNAPSHOT{color}
** {color:#00875a}create tag v1.0.0 with pom version 1.0.0{color}
** {color:#00875a}create branch v1.0.0{color} {color:#ff8b00}with pom version
1.0.0-SNAPSHOT{color}
** {color:#00875a}deploy artifact 1.0.0 in the repository{color}
* Run#2 on trunk (release the 1.0.1 version)
** {color:#00875a}trunk version changes to 1.0.2-SNAPSHOT{color}
** {color:#00875a}create tag v1.0.1 with pom version 1.0.1{color}
** {color:#00875a}create branch v1.0.1{color} {color:#ff8b00}with pom version
1.0.1-SNAPSHOT{color}
** deploy artifact 1.0.1 in the repository
* Run#3 on trunk (release the 1.0.2 version)
** {color:#00875a}trunk version changes to 1.0.3-SNAPSHOT{color}
** {color:#00875a}create tag v1.0.2 with pom version 1.0.1{color}
** {color:#00875a}create branch v1.0.2{color} {color:#ff8b00}with pom version
1.0.2-SNAPSHOT{color}
** deploy artifact 1.0.2 in the repository
* Run#4 on branch v1.0.1 (release the 1.0.1.0 version)
** {color:#ffab00}branch version changes to 1.0.2-SNAPSHOT (same as
trunk){color}
** {color:#de350b}copy branch over tag v1.0.1 with pom version 1.0.1
(*){color}
** {color:#de350b}copy branch over branch v1.0.1 with pom version
1.0.1-SNAPSHOT (*){color}
** {color:#de350b}override artifact 1.0.1 in the repository => (**) {color}
Here are tips from my scripting:
(*) I use svn info. If it returns 1 then the branch or tag does not exist.
(**) initially I used wget but I finally prohibit artifact updates on the
repository settings.
> 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.1#820001)
[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[ https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467944#comment-17467944 ] Michael Osipov commented on MRELEASE-1073: -- Now the problem is clear: You are using the wrong versioning scheme. You need to switch to a three-digit scheme and this plugin will the correct incrementation. > 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.1#820001)
[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[ https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467933#comment-17467933 ] Stéphane Passignat commented on MRELEASE-1073: -- Thanks Michael, I actually run this process on several applications and libraries and would like to make it stronger, while migrating some apps from svn to git, as it actually uses shell scripts to run which is kind of painful, only runs on linux, ... while the SCM and version API of the plugin here are great. *About the release process* I use the branch feature to create the maintenance branch. So in trunk I have 1.0-SNAPSHOT producing 1.0 artifacts and update version to 1.1-SNAPSHOT... In the generated (maintenance) branch I would like to generate 1.0.0, 1.0.1 patch version but the version is still 1.0-SNAPSHOT. Then when I release from this branch (without paying attention) I generate a 1.1 version which can override the 1.1 version in the artifact repository produced from the trunk. So it would be great to change the version in the generated branch or to have an option to generate a patch branch with the version properly modified. !image-2022-01-03-12-14-20-084.png! * In red what (we) want to achieve * In green what's currently happening *About beta process.* What do you mean by _'Tag from beta isn't a problem. Works straight away.'_ ? This can be done in this plugin ? or does this already exists ? > 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.1#820001)
[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[
https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467847#comment-17467847
]
Michael Osipov commented on MRELEASE-1073:
--
* Tag from beta isn't a problem. Works straight away.
* This isn't the task of this plugin, it is a *release* plugin, *not* version
chainging one. Use {{versions-maven-plugin}} for that.
I still don't the the usecase which isn't working with this plugin. I strongly
urge you to try your entire process on a test repo.
> 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
>
>
> 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)
[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[ https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467712#comment-17467712 ] Stéphane Passignat commented on MRELEASE-1073: -- (I just update the diagram to be more accurate). I hope it's the standard process. What's missing (or I didn't find it yet in this plugin) is: - to generate tag for beta with the plugin - to change the version in generated branch to a sub-version (patch) ex: 1.0.0-SNAPSHOT > 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 > > > 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)
[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[ 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)
[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[ https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467699#comment-17467699 ] Stéphane Passignat commented on MRELEASE-1073: -- Here is a view of what how releases works and how we could improve with a prerelease feature. !screenshot-3.png! In green the release features available. In red the prerelease feature I'm thinking about, which compute the beta number, check the new number is "greater" than the last one: greater number at the end or greater in alphabetic order (maven rules). > 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: screenshot-1.png, screenshot-2.png, screenshot-3.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)
[jira] [Commented] (MRELEASE-1073) Pre-Release generation
[
https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467476#comment-17467476
]
Michael Osipov commented on MRELEASE-1073:
--
I don't really understand the purpose of your request. If you moved from
SNAPSHOT to {{-beta-13}} the Release Plugin will properly increment here. If
you are not happy with the release policy, you can write you own. Please
explain.
> 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
>
> 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)
