CandleWith a pull-request based workflow (and a protected `main` branch), how do people handle `mvn release:prepare` via a branch & pull request?
dreamrealwouldn't that be the CI/CD's job in that case?
CandlePartly, let's restrict that even more, and say that CI/CD does not have write access to the repo.
dreamrealdon't know then
dreamrealgpt
dreamreal~gpt With a pull-request based workflow (and a protected `main` branch), how do people handle `mvn release:prepare` via a branch & pull request?
javabotIn a pull-request based workflow with a protected `main` branch, you'd typically handle `mvn release:prepare` via a branch & pull request by creating a separate release branch. Here's a simple process: 1. Checkout to a new branch (e.g., `release/v1.0.0`). 2. Run `mvn release:prepare` in that branch. This will update the project versions, commit, and tag the new version. 3. Push the branch and create a pull request for it. 4. Once the pull request is re
javabotbe merged into the `main` branch. This way, `mvn release:prepare` is executed in a controlled environment and the `main` branch is updated in a clean, traceable manner through the pull request.
* dreamreal shrugs.
CandleIt is feels like a fast-forward merge - to get the two sequential commits into main, but then the tag still references a commit on the branch.
deebowhat does release:prepare do?
dreamrealI'd think you'd tag the release preparation, not the incoming
Candle1. commits a non SNAPSHOT version (e.g. changes 1.0.5-SNAPSHOT to 1.0.5). 2. creates a tag at that commit. 3. commits the next SNAPSHOT version (e.g. 1.0.6-SNAPSHOT).
deebodo you really need like a pom.xml with <verion>5.0.0</version> in the repo? with gradle we just rewrite the the version for the build when releasing
dreamrealmore than one road to rome
CandleHaving the release version in VCS That gives you something you can tag in the repo.
deebotrue, it just seems weird (to me), main/master should produce a snapshot every time, a separate release pipeline builds a specific commit as a release
Candle(this is a long-standing problem that stricter repository permissions are ... encouraging.. us to actually try to resolve!)
* dreamreal shrugs. Everyone has a lot of local practices, and somehow the world manages to not end as a result
deebowe just ./gradlew build && ./gradlew -Pversion=2026.q2 publish && git tag release/2026.q2
deebosnapshots are satans tool against humanity, along with nodejs and xml
dreamrealthat's just about my process, too, although I don't use gradle
dreamrealand I have no problem with either nodejs nor XML
dreamrealmost people who resent XML resent its verbosity and don't know it
dreamrealnot all, but most
Candledeebo: Depending on a SNAPSHOT in production, that is certainly satanic!
deebowell hopefully noone does that, and no doubt the situation has improved but i just hated trying to get an actual update to a dependency as a snapshot to work
CandleAlso, switching to use Gradle is a pretty much a non-starter due to the size of the team and quantity of code.
deebodon't repositories require unique snapshots these days anyhow? they append like a timestamp, :1.0-SNAPSHOT ~ :1.0-SNAPSHOT-2026041309101213.999 or something
deeboremember dealing with that when managing a nexus repo and older maven versions that tried to overwrite snapshots or something
CandleOnly if you push that snapshot to a repo.
* roesyyu joined #java
* roesyyu joined #java
* roesyyu joined #java
* Fiji_ joined #java
* kcomhnall joined #java
* GreenResponse joined #java
Parabtw, never do fast-forwarding merges
ParaThey break actual history by removing merge points, and merge points are semantically important
* roesyyu joined #java
dreamrealI just don't use VCS, makes management a lot easier
* roesyyu joined #java
* roesyyu joined #java
Paramanage, damage, same difference
* roesyyu joined #java
* roesyyu joined #java
cheeserdeebo: they've always had timestamps on snapshots.
GreenResponsenice piece, I think there’re too many people using computer technology, some only to “fit in” because of FOMO, they absorb solutions given them by AI because they are incapable of make them themselves
Swayzeyeah but then you need to have teh right person for the rigth job
Swayzeif its a personal project it doesnt matter what you're doing but in a professional setting there are ways to ensure you have the appropriate person in charge of architecting solutions and making decisions
* B_fd joined #java
* mindCrime joined #java
* zorone joined #java
* deepSleep joined #java
* Zapek joined #java
* Zapek joined #java
* Betal joined #java
GreenResponseI was thinking more about end-users than developers tho
* roesyyu joined #java
* dumptruckman joined #java
* johnjay joined #java
* agnivn joined #java
* MikeBux joined #java
* Ekho joined #java
* stfstfm joined #java
* polarian joined #java
* m joined #java
* NeXeN joined #java
* nevet joined #java
* CodeGeek!~codegeek@about/java/CodeGeek changed the topic to: Welcome! || Read Channel Rules at https://javachannel.org/ before participating. || Paste limit is two lines; ~pastebin lists options. || No applets, please. || Minecraft, Android, and Javascript all have their own channel. || You are being logged.