8000 chore[ci]: disable semver check until it has a lock filie by joseph-isaacs · Pull Request #6451 · vortex-data/vortex · GitHub
[go: up one dir, main page]

Skip to content

chore[ci]: disable semver check until it has a lock filie#6451

Merged
joseph-isaacs merged 4 commits intodevelopfrom
ji/disable-semver-check-until-fixed
Feb 12, 2026
Merged

chore[ci]: disable semver check until it has a lock filie#6451
joseph-isaacs merged 4 commits intodevelopfrom
ji/disable-semver-check-until-fixed

Conversation

@joseph-isaacs
Copy link
Contributor
@joseph-isaacs joseph-isaacs commented Feb 12, 2026

We can re-enable once the check is updated to use a lock file or something

Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
@joseph-isaacs joseph-isaacs added the changelog/chore A trivial change label Feb 12, 2026
@joseph-isaacs joseph-isaacs marked this pull request as ready for review February 12, 2026 12:46
@joseph-isaacs joseph-isaacs enabled auto-merge (squash) February 12, 2026 12:46
@joseph-isaacs joseph-isaacs merged commit aeed3bd into develop Feb 12, 2026
47 checks passed
@joseph-isaacs joseph-isaacs deleted the ji/disable-semver-check-until-fixed branch February 12, 2026 12:58
fastio pushed a commit to fastio/vortex that referenced this pull request Mar 10, 2026
…a#6451)

## Does this PR closes an open issue or discussion?

<!--
This helps us keep track of fixed issues and changes.
-->

- Closes #.

## What changes are included in this PR?

<!--
What changes are included here, if an issue or discussion are attached,
there's no need to duplicate the details.
-->

## What is the rationale for this change?

<!--
Why do you propose this change, and why did you choose this approach.

This helps reviewers and other readers understand changes, creates a
shared understanding of the issue and codebase,
and improves their ability to work with this change and offer better
suggestions.
-->

## How is this change tested?

<!--
Changes should be tested, we expect changes to fit in one of the
following categories:
1. Verifying existing behavior is maintained.
2. For serialization related changes - Compatibility should be
maintained or explicitly broken.
3. For new behavior and functionality, this helps us maintaining that
desired behavior in the future.
-->

## Are there any user-facing changes?

<!--
Does the change affect users in what of the following ways:
1. Breaks public APIs in some way.
2. Changes the underlying behavior of one of the integrations.
3. Should some documentation be changed to reflect this change?

In the case some public API is changed in a breaking way, make sure to
add the appropriate label.
-->

Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

changelog/chore A trivial change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

0