apache / apache/maven-release

[MRELEASE-1030] Introduce flag to push once, not twice, during release:prepare

Open
#1,210 0 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Java
Stars
128
Forks
145
Avg merge
7h 7m
Merged PRs (30d)
3

Description

**[Daniel Burrell](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=danielburrell)** opened **[MRELEASE-1030](https://issues.apache.org/jira/browse/MRELEASE-1030?redirect=false)** and commented

## Scenario:

When performing `release:prepare` the following action is taken.
* solidify releases
* commit and push
* tag this commit
* push tag
* move to next snapshot
* commit and push

## Problem:

This behaviour in a git based CI environment results in additional unnecessary builds as an untagged commit is delivered, quickly followed by the same commit in tagged form. Build systems are setup to look for tagged commits to initiate a release process, but the double push results in a 2 builds: (the same code, but one untagged).

## Proposal:

The commit and push that happens in stage 2 above should be a commit only.

The push should be a push of the tag (which implicitly pushes the commit).

To maintain backward compatibility this behaviour should be a flag, with the default to current behaviour.

If this plugin is built on the scm code base then I suspect this is down to generic usage of the scm, without consideration of the nuances of git. (Pushing after every commit). The scm plugin does indeed have a flag for this purpose but we are not making use of it or allowing it to be configured in the release plugin.

I think `pushChanges` [here|#l95]] would suppress all pushes from being committed including the tag and nextsnapshot commits, and so would not work.

---

**Affects:** 2.5.3

**Issue Links:**
- [SCM-970](https://issues.apache.org/jira/browse/SCM-970) Have separate APIs for distributed and centralized version control
(_**"depends upon"**_)

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by tracing the release:prepare stages described in the issue and the existing pushChanges configuration, then review the linked SCM-970 dependency. Determine how the SCM API can commit without pushing while still pushing the tag, and how a new flag preserves the current default behavior. Done means the optional mode avoids the first push without suppressing the tag and next-snapshot commits.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, java
Domain
build-system, release
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.