[
https://issues.apache.org/jira/browse/MRELEASE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468060#comment-17468060
]
Stéphane Passignat edited comment on MRELEASE-1073 at 1/3/22, 5:01 PM:
-----------------------------------------------------------------------
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, ... 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.
was (Author: JIRAUSER281033):
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)
