Add fold option to avoid version code jumps such as v1.2.3 -> v8.6.3
#45
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes it easier to make manual changes to the original version number.
|
I did NOT read the code closely enough when making these changes. Working on an actually working version. |
…ruct This makes version codes easier to work with and consider a single entity.
This looks like an oversight which could result in `RELEASE_IS_NEXT_VERSION_COMPATIBLE_WITH_CODEPUSH` erroneously reporting true or false when compared with `RELEASE_LAST_INCOMPATIBLE_CODEPUSH_VERSION`
…vidual responsibility clearer `is_releasable` and `is_codepush_friendly` does more and other things than their names suggest. Primarily, they modify the `lane_context` (unexpected side effects) but `is_codepush_friendly` also does not actually answer this question. This commit renames `is_releasable` to `calculate_versions` and `is_codepush_friendly` to `calculate_last_codepush_incompatible_version`. The commit also extracts `lane_context` modifications to a separate method. This commit does cause slight breakage in that the `RELEASE_LAST_INCOMPATIBLE_CODEPUSH_VERSION` context variable will not be set if `get_beginning_of_next_sprint` fails. However, I believe this to be an error state - which should probably throw or something - anyways and have thus ignored this slight behavioral change.
FelixZY
force-pushed
the
master
branch
3 times, most recently
from
fab81ec to
a26b387
Compare
This reduces code duplication and is more expected from a method "get commits". This change also applies the `SemanticReleaseHelper.should_exclude_commit` filter for `calculate_last_codepush_incompatible_version`. I do not know why this filter was not applied here previously but assume its omission to be a bug.
This will be used to optimize `calculate_last_codepush_incompatible_version` and reduce code duplication.
…lculate_commit_version`
This commit primarily aims to reduce code duplication, improve readability and enforce a stricter
"one task per method" mindset. The commit also aims to optimize the codepush incompatible
commit calculation.
The commit attempts to achieve these goals by:
* Improved naming
* Explicit parameters rather than `params`
* A centralized `calculate_commit_version` method
* Working from the most recent commits rather than the oldest when calculating codepush
incompatible commits
* introducing the ability to retrieve the previous release for *any* commit, not just the most
recent one
I have tried to retain backwards-compatibility from a user standpoint (i.e. the program
behaves the same as it did before). However, a few log messages were not possible to include
in a simple way without incurring log-specific overhead:
* "Found a tag #{tag_name} associated with version #{version}" - would either print multiple
times or not at all. I opted for the latter.
* "Found #{commits.length} commits since last release" - I'm using lazy iterators and therefore do
not know the number of commits beforehand. Also, due to code deduplication, this would now
print multiple times. For these reasons, I opted for removal.
As compensation, I added two new log prints:
* "Last version: #{last_version}"
* "Next version: #{next_version}"
As noted in xotahal#11, for some users that are used to [semantic-release](xotahal#11) it is quite unexpected that the version number increments _for each commit_ rather than _per changeset_. This commit introduces the more expected behavior as a non-breaking change via the optional `fold` parameter. I have not added new tests at this time as implementing this has taken way longer and grown more complex than I intended.
|
Now it's fixed. As noted in my last commit, I have not added tests for the |
…und `calculate_commit_version` Fix invalid params reference
…und `calculate_commit_version` Fix invalid backup return (expected 2 values, got 1)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've used semantic-release before where each version increment is quite minimal.
E.g.
would result in a version bump to
major.minor+1.0rather thanmajor.minor+1.patch+1, which is the behavior of this repo. This issue was discussed in #11 where @xotahal welcomed contributions - so here it is 😉 .#11 also discusses support for "locked" version numbers. However, this is not something I have implemented at this time as I think it warrants further discussion first. Personally, I think the behavior of semantic-release should be imitated.