Here, SecretlyIterator is public API, but its impl Iterator is not. That impl is pub, but pub != public API.
The impl Iterator may be designed only for use by macros. Downstream users of this crate should not rely on its existence directly, as removing it is not semver-major.
My "SemVer in Rust" talk from @fosdem is now available as a blog post!
I used the "annotated talk" format pioneered by @simon to make it easy to skim the material, skip ahead, and jump between the written post and the video.
By default, calling (sijo-version:version) will give you a version based on your system or VERSION file and current git branch and commit. But it's configurable using a small EDSL, and will construct something like 0.1.0-0.dev.27+prototype.7aeedb4d32927e19a5e9ed406ac5735db0fd20dd.20240301145715Z or 0.1.0+8e523641c17ca0db45af33e159a3fe08a993c1d8.20240311182000Z.
A little #Emacs#package I made to easily see what #semver constraints translate to in the echo area. For example to ensure that ~1.1.0 actually does translate to >=1.1.0 <1.2.0 and avoid mistakes!
A deeper dive than anybody wanted into Semantic Versioning, how its ordering conflicts with standard practice, and how to unify spec and practice. Includes examples for SBT (Coursier and Ivy) and Maven.
PSA: when you use #semver (Semantic Versioning) for your project, please stick to the rules. Breaking (API) changes require a major version bump. Please don’t break the API between 1.4.x and 1.5.x. Because that’s unexpected behaviour and really bad for users of your project. #kthxbaihttps://semver.org/
Reflecting on the 2023 highlights of cargo-semver-checks
✨ running 2x the lints in 1% the time
✨ eliminated 60% of false-positives
✨ 1 in 6 of Rust's top 1000 crates have accidentally broken semver in a way we can now detect & prevent.
Also, your regular reminder that this work is funded by GitHub sponsorships. The limiting factor is money: the better I can pay the bills with this, the more time I'll be able to spend on it.
Given how Pydantic 2 broke compatibility with Pydantic 1 in a way that's still shaking out - you can't use 2 in a project that has dependencies that use 1 without making changes to those dependencies...
... I wonder what the downsides of releasing Pydantic 2 as a new package called "pydantic2" such that it could be installed in the same namespace as the original pedantic would have been?
Presumably this is how Jinja ended up as "jinja2" forever?
@simon on that note, I'm working on a Python linter that can find and report breaking changes between package versions!
Like my Rust linter cargo-semver-checks, but for Python. Before making a new release (or merging a PR), run it to make sure no unintended breaking changes have snuck in.
Who should I be talking to about this? Who needs to use it the most?
Well, I've hopped on the #SemVer train. Here's a new tool named Thaw which lets you easily update your #Nix Flake's inputs' refs. That means you can get safe version upgrades without needing to rely on another server, everything happens locally! Currently compatible with GitHub, but can be pretty easily extended to support other sources. Contributions welcome!
Does anyone know of a semver inspired release system tied in with Github Actions (or equivalent) that will let me write "conventional" commit messages for a Python project, and have some magic happen where version numbers are updated in setup.py, tags are made/releases cut, etc etc?
@voxpelli Agree, the appearance of using #semver is the worst part about it - it messes with all assumptions you might have seeing the version.
But I also think semver would still be a good choice!
I don't get why some projects are so afraid of doing major version bumps often. The changes are breaking anyways, it's not like it's more difficult to update because of the major version.
Don't be so afraid of reaching a major version in the two or three digits.