Skip to content

chore: release master - #313

Merged
lachlangrose merged 1 commit into
masterfrom
release-please--branches--master
Aug 14, 2026
Merged

chore: release master#313
lachlangrose merged 1 commit into
masterfrom
release-please--branches--master

Conversation

@github-actions

@github-actionsgithub-actionsBot commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

🤖 I have created a release beepboop

1.7.2

1.7.2 (2026-08-14)

Bug Fixes

  • keep unprefixed v* tags for the LoopStructural release-please component (006ae79)
  • keep unprefixed v* tags for the LoopStructural release-please component (1a038f6)
  • track LoopStructural version in pyproject.toml instead of version.py (449f38d)
  • track LoopStructural version in pyproject.toml instead of version.py (b90babb)

This PR was generated with Release Please. See documentation.

@lachlangrose

Copy link
Copy Markdown
Member

Do not merge — release-please picked the wrong tag-naming baseline (looking for LoopStructural-v* tags that don't exist, since this repo's tags are plain v*) and computed a regressive 1.6.5 as the next version. Fix incoming in a follow-up PR; this one should be closed once that lands and release-please regenerates it.

@github-actions
github-actionsBotforce-pushed the release-please--branches--master branch from 89f2897 to 69d9541CompareAugust 14, 2026 06:56
@lachlangrose
lachlangrose merged commit 287e2f6 into masterAug 14, 2026
2 checks passed
@lachlangrose
lachlangrose deleted the release-please--branches--master branch August 14, 2026 06:58
lachlangrose added a commit that referenced this pull request Aug 14, 2026
#314 deleted this file, but the release-please run triggered by that
same merge re-created it with __version__ = "1.7.2" (LoopStructural's
version, not loop_interpolation's real "0.0.1") before PR #313 was
merged. Its own filename-search log line still showed the file as
found on that run -- most likely GitHub's code-search index hadn't
caught up with the deletion commit yet.
Root cause: pointing the LoopStructural component's path at "." makes
release-please's "find any file named version.py" search genuinely
repo-wide rather than scoped to LoopStructural/, so it can collide
with any version.py anywhere in the tree, present or future (e.g. the
still-unmerged map2loop/loopstructural_visualisation packages each
have their own). There's no release-please config to scope that search
to a subpath, so the durable fix is having no other version.py files
left for it to find.
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
rolandhill pushed a commit to rolandhill/LoopStructural that referenced this pull request Aug 26, 2026
…mponent
Repointing the LoopStructural component's path to "." (in Loop3D#312) let
release-please discover its component name from pyproject.toml, which
flipped it to the manifest-mode default of prefixing tags with the
component name (LoopStructural-v*). No such tags exist -- every past
release used a plain v* tag -- so release-please couldn't find the
real last release and fell back to an ancient v1.6.5 tag as its
baseline, computing a regressive "next version" of 1.6.5 in PR Loop3D#313.
include-component-in-tag: false restores the historical plain v* tag
scheme so release-please finds v1.7.1 as the last release again.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@lachlangrose