Skip to content

bump version to v0.3.1#46

Merged
dicej merged 1 commit intobytecodealliance:mainfrom
dicej:bump-version-to-v0.3.1
Apr 7, 2026
Merged

bump version to v0.3.1#46
dicej merged 1 commit intobytecodealliance:mainfrom
dicej:bump-version-to-v0.3.1

Conversation

@dicej
Copy link
Copy Markdown
Contributor

@dicej dicej commented Apr 7, 2026

Unlike the v0.3.1 tag I just pushed, this leaves the Go wrapper pointing to the "canary" release rather than the v0.3.1 release, since this PR targets the main branch.

Unlike the `v0.3.1` tag I just pushed, this leaves the Go wrapper pointing to
the "canary" release rather than the `v0.3.1` release, since this PR targets the
`main` branch.
@asteurer
Copy link
Copy Markdown
Contributor

asteurer commented Apr 7, 2026

I'm a bit lost...Did you intentionally leave the release variable as canary in the main.go file?

@dicej
Copy link
Copy Markdown
Contributor Author

dicej commented Apr 7, 2026

I'm a bit lost...Did you intentionally leave the release variable as canary in the main.go file?

Yes, because this PR is aimed at main, where "canary" is the appropriate release to use. In contrast, the commit I used for the v0.3.1 tag changes it to point to "v0.3.1".

In other words, the commit which the v0.3.1 tag points to will never land in main since the main branch should always point to canary. Another way to do it would be to update both the version and the release variable to point to the tag, land that in main, then immediately push another commit which changes it right back to "canary", but that seems like more work.

I'm open to suggestions on how to make this less confusing!

@dicej
Copy link
Copy Markdown
Contributor Author

dicej commented Apr 7, 2026

I guess the other option would be to just always point the Go wrapper at the latest stable release, even in main. That would certainly simplify the whole process. Everyone would just need to understand that using the Go wrapper from main is the same as using the latest stable release of the Go wrapper, modulo any fixes specific to the wrapper itself.

Copy link
Copy Markdown
Contributor

@asteurer asteurer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really have a strong opinion on the tool targeting canary or latest on main. Happy to defer to whatever you think is best.

@dicej
Copy link
Copy Markdown
Contributor Author

dicej commented Apr 7, 2026

I don't have a strong opinion either. Let's have main point to "canary" for now, and we can revisit later if it seems too confusing.

@dicej dicej merged commit dc6e0f6 into bytecodealliance:main Apr 7, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants