Replies: 3 comments 7 replies
-
I believe this could do it, but I'm not entirely sure yet. {
"branches": ["master", { "name": "alpha", "prerelease": "alpha" }],
"plugins": [
[
"@semantic-release/commit-analyzer",
{
"preset": "angular",
"releaseRules": [{ "type": "native", "release": "premajor" }]
}
],
"@semantic-release/release-notes-generator"
]
} Start on Push a Now we're at And then: git commit -m 'native: added some native code' Should this do a |
Beta Was this translation helpful? Give feedback.
-
@travi any shot you know if this is possible or not? Thanks again! |
Beta Was this translation helpful? Give feedback.
-
so, i think the main thing to give the appropriate context to answer this question comes from the relationship between the name of semantic-release and semantic versioning. one of the deepest core purposes of semantic-release is to make semantic versioning simpler to follow correctly. the "semantic" intent is to communicate the impact of the changes in a version since the previous version, so that a consumer understands the level of risk involved in updating. it seems like you are wanting major version increments that arent necessarily communicating breaking api changes to consumers. to expand, a pre-release is about stability of a release channel on it's way to be promoted to a stable version. because a pre-release is intended to be unstable, multiple breaking changes released to that channel are not intended to increase the target version number beyond a single major bump. this is also true of multiple bug fixes or new features. semantic-release, therefore, bumps the pre-release version number a single increment of the highest impact segment included in that branch. this is by design. the closes supported approach to what you describe would be to merge your prerelease branch into the mainline branch so that the pre-release is promoted to stable. then you can create a new pre-release branch for the increments that are intended to follow that initial major bump. in addition, it is intended for semantic-release to be responsible for the entire release process. it seems like you are wanting to relate part of the release process that you are intending to be driven by semantic-release with a separate external release process. semantic-release is a tool to assist in following semantic versioning properly i an automated fashion to prevent mistakes. while it can be twisted to enable other workflows and can be seen as valuable that way because of the pieces that it can automate, those are outside of our supported use cases. semantic-release is not intended to be a general purpose release tool. |
Beta Was this translation helpful? Give feedback.
-
TLDR
Is there a way to force pre-release versions to do a major version bump on every
BREAKING CHANGE
, and not just the first breaking change?The docs indicate that if you do a
BREAKING CHANGE
on a pre-release branch, it will go from1.0.0
=>2.0.0-alpha.1
. That's exactly what I'd expect.However, it seems like a second
BREAKING CHANGE
onalpha
would increment it to2.0.0-alpha.2
. I understand that this may be desirable for many use-cases.However, for my use-case, I want any usage of
BREAKING CHANGE
, even in a pre-release branch, to do a major version bump.Example
alpha
:1.0.0
→2.0.0-alpha.1
alpha
:2.0.0-alpha.1
→3.0.0-alpha.1
The reason I want this is that I'm tying my major version changes to native code in my React Native app. If (and only if) my major version changes, I need to ship a new binary to the app store.
A pre-release branch is no exception. For every pre-release major version, I ship to TestFlight for testing.
For any non-breaking changes, I just ship an over-the-air update to the corresponding major version.
With the current setup, the major version doesn't increment more than once on a pre-release branch. This would lead to my CI not rebuilding on the app store as it needs to.
Beta Was this translation helpful? Give feedback.
All reactions