DATAGO-70348: Publish quarkus to Maven Central #57
Conversation
| <configuration> | ||
| <serverId>ossrh</serverId> | ||
| <nexusUrl>https://s01.oss.sonatype.org/</nexusUrl> | ||
| <autoReleaseAfterClose>false</autoReleaseAfterClose> |
There was a problem hiding this comment.
This is what will need to be updated to allow the release action to distribute the package publicly without extra approval
|
@clarkbains. Below are my answers to your questions
|
|
@clarkbains I am checking if we can enable githubpages for this repo to host documentation. I will confirm on this so that we can exclude docs from release pipeline |
| @@ -9,23 +11,14 @@ | |||
| </parent> | |||
| <groupId>com.solace.quarkus</groupId> | |||
| <artifactId>quarkus-solace-parent</artifactId> | |||
| <version>999-SNAPSHOT</version> | |||
| <version>0.0.1-SNAPSHOT</version> | |||
There was a problem hiding this comment.
is 0.0.1 our general standard for development snapshots or can we leave it to 999?
There was a problem hiding this comment.
@ozangunalp FYI.
There was a problem hiding this comment.
Check out the releasing.md doc to see what the commits on main will be like. The intention is that main would always be one patch number higher than the last released version. I didn't have to pick this version but I figured it would be overwritten soon whenever this is released.
But we can also use release branches if you'd prefer. It currently has some support for this but we can automate the branch creation too if this is the only way you intend to develop. That way main and all features branches can stay as 999.0.0-SNAPSHOT, then only the release branches will have proper versions.
There was a problem hiding this comment.
When you go to release from main, the action will first make a commit where the version is set to the release version. Then it will build / deploy / tag it. Then it will increment the patch number and add snapshot again, so after a 1.0.0 release from main, main would be 1.0.1-SNAPSHOT.
Then if you select auto version for the next release from main, you wouldn't need to enter 1.0.1. the default auto version will select that for you, or if it was a breaking change / new feature you could specify the new release version manually, like 1.1.0 instead
There was a problem hiding this comment.
Okay, so that means a commit is always triggered to update all the pom's during the release process?
There was a problem hiding this comment.
Yes, two commits are pushed on whatever branch it is released from
One to set to the desired version, which is what we deploy (eg 1.0.0)
and then one more that increments the patch version and adds -SNAPSHOT (eg 1.0.1-SNAPSHOT).
There was a problem hiding this comment.
Okay. This will update all the modules irrespective of whether they are included in release pipeline, correct? My only concern is that pom is updated for every release we trigger. How much time do you think it will take if we switch to release branch process. If you think it takes more time to switch to second option(release branches) we will use the current process considering our release commitment to maven.
I am approving the current changes.
|
@SravanThotakura05 I've updated to run and report test results prior to committing any of the version bump commits. This will allow retrying the release if the project is not passing tests. |
We can exclude docs from release pipeline. We will host in Github pages |
Pre merge action items
Post merge action items
pom.xmlto automatically release on ossrh (Currently it will be held back for manual approval, just to make sure all is well with the automation)Questions