Add release-start mojo

[slawekjaranowski]

• Introduced the release-start mojo to create a draft release in ATR if it does not exist.
• Updated documentation and site navigation for the new mojo.
• Added unit tests and integration tests for release-start functionality.

[hboutemy]

create a draft release in ATR if it does not exist

"if it does not exist" means that this new goal IMHO should be in fact merged with check-composing

should we keep release-start as target or check-composing (or start-release), I don't have firm opinion yet

I'm trying to guess how this will be integrated

• in real global process: https://maven.apache.org/developers/release/maven-project-release-procedure.html
• and in parent POM: https://maven.apache.org/pom/asf/

we do mvn release:prepare = where we define the target version number is done
followed by mvn release:perform with future -Ppush-to-atr profile: ok, that profile will check or create the version in ATR

seems ok: just 2 goals is too much, one only seems sufficient

[hboutemy]

notice: for now, key step is ATR project creation, from .asf.yaml: perhaps we could display if .asf.yaml definition is done

and I think the key missing configuration is the vote templates, that is not available in .asf.yaml (and is too chatty IMHO to get added there)

the more we add in the Maven plugin, the more we should already test in real life what we have

[slawekjaranowski]

notice: for now, key step is ATR project creation, from .asf.yaml: perhaps we could display if .asf.yaml definition is done

and I think the key missing configuration is the vote templates, that is not available in .asf.yaml (and is too chatty IMHO to get added there)

the more we add in the Maven plugin, the more we should already test in real life what we have

It is each PMC responsibilite how to configure ATR, can be done be asf.yaml or by web gui, I would like to not introduce such configuration goals, like for templates and so on.

Plugin should be used during release proces, as you wrote the more in plugin more in test

[slawekjaranowski]

create a draft release in ATR if it does not exist

"if it does not exist" means that this new goal IMHO should be in fact merged with check-composing

should we keep release-start as target or check-composing (or start-release), I don't have firm opinion yet

I'm trying to guess how this will be integrated

• in real global process: https://maven.apache.org/developers/release/maven-project-release-procedure.html
• and in parent POM: https://maven.apache.org/pom/asf/

we do mvn release:prepare = where we define the target version number is done followed by mvn release:perform with future -Ppush-to-atr profile: ok, that profile will check or create the version in ATR

seems ok: just 2 goals is too much, one only seems sufficient

yes two goals for the sam can be too much ...

I would like to have release process simple as possible, I will prepare proposition for integration in next steps

[slawekjaranowski]

should we keep release-start as target or check-composing (or start-release), I don't have firm opinion yet

I would like to have only release-start in release flow, it will be one less manual step, even we want to manually re-deploy during release that goal will not create version again in atr

[hboutemy]

"release flow" is really vague
mvn release:prepare release:perform is not vague: do you expect other approaches?

[hboutemy]

given normal users do not yet have habits on reviewing project definition in ATR, automating the release start at ATR level seems too early to me

users need to learn, not use blindly

let's do a first release integrated in ASF parent POM before trying to automate more: I hate automating things before manual experience = from experience, a recipe for complaints when the magic does not bring expected result

[slawekjaranowski]

"release flow" is really vague mvn release:prepare release:perform is not vague: do you expect other approaches?

yes projects can do release without release plugin, like:
https://logging.apache.org/logging-parent/release-instructions-project.html

[hboutemy]

do what yuo want, I'm tired not being able to do a release but continuing complexifying

[slawekjaranowski]

given normal users do not yet have habits on reviewing project definition in ATR, automating the release start at ATR level seems too early to me

it will only create a release version in ART

users need to learn, not use blindly

let's do a first release integrated in ASF parent POM before trying to automate more: I hate automating things before manual experience = from experience, a recipe for complaints when the magic does not bring expected result

agree here, we can prepare configuration in ASF parent, but should be in disabled by default (or in dryRun)

so I see a three goal for integration:

• start-release - create a version
• upload - upload project release artifacts ... but it can be tricky, like project need provide a files list to upload
• upload-sboms - upload sbom artifact to art ( new goal - Support uploads of mvn generated SBOMs #44 )

[hboutemy]

can we postpone adding more complexity please?
I wrote one month ago the plan for push-to-atr profile to give needed flexibility: and I'm fighting to just do a release

can we finish first the first step?

[slawekjaranowski]

can we postpone adding more complexity please? I wrote one month ago the plan for push-to-atr profile to give needed flexibility: and I'm fighting to just do a release

can we finish first the first step?

I hope not complexity I'm tring to find a way to be simple as possible when we add profile to ASF parent ...

connected issue:

• Review docs about Integration with Release Profile #48

[hboutemy]

I know you have good intents
I prefer forcing people to review their project configuration in ATR UI and click on "start release"
than the magic where they discover after the fact ATR config

we need to find the right training path, "to be simple as possible" but avoid the "to be magic" then have people ask about what happened behind the scene