Ah whoops, I didn't realize 0.8.0-rc.1 was the semver standard, sorry! I copied the style I'm doing from some other projects on Github, so I assumed it was common. Didn't bother to check the standard, doh!

I'm basically doing what you describe with 0.8.0-rc.1, 0.8.0-rc.2 but moving the incrementing number to the last digit of semver makes it easier to parse by version comparison software, including my own new https://github.com/ArchiveBox/pydantic-pkgr

Given the massive scope of changes in the 0.8 alphas, I might actually jump straight to 0.9 for the final release, it's likely the biggest release in ArchiveBox history and I want to avoid any confusion so I'll just skip a number to make it obvious that it's a big new release.

The reason this release is so big is I'm officially pluginizing all of archivebox, and making all of the internal behavior hookable using https://pluggy.readthedocs.io/en/stable/index.html, very similar to the new https://github.com/simonw/djp by @simon987. It's hard to do incrementally so I'm doing it all in one go (one of the luxuries of being a solo developer is I can do complete rewrites still, I would never subject a team to that). A big benefit is that I get to clean up a lot of the old legacy cruft in the process, and add pydantic-enforced type safety in a lot more places.

(this also opens up a future world of compatibility with nodejs and other languages, as all the interfaces can now be defined in json/yaml and loaded by pydantic across language barriers)

Because this rewrite is a multi-month refactor I didn't want to keep everyone waiting and give the public the impression that the project is going stale, so I started releasing these pre-releases as a way to keep myself accountable, get some incremental feedback, and force myself to write release notes to keep track of the differnces for the eventual big v0.9 anncouncement.

I'm open to suggestions on how to improve the communication here though! Should I add more disclaimers to the release notes to explain this better?

I track this repo cuz I run archivebox locally and work on the Pocket & Readwise extractors, so most of this I was aware of. It was the versioning specifically that confused me. I think you can just leave this issue open until 0.9.0 and close it then and move to semver RCs after that.

Also, Pluggy seems neat, seems useful for another project I have.

Ok cool, I updated the release warning header with some more clarification too:

FYI I have now adopted the v0.8.5rc123 numbering scheme for tagging minor bugfix builds under each 0.8.x pre-release.

The RC number at the end gets bumped for small changes/bugfixes, e.g. v0.8.5rc51 comes after v0.8.5rc50, etc...
For breaking changes or bigger groups of changes I'll increment the semver minor version and reset the RC number to 0, e.g. v0.8.6rc0 + I'll publish an entry on the ArchiveBox releases page describing the changes (like we have so far for the v0.8.x series).

The entire v0.8.x series is still BETA-only (including all minor semver/rc version bumps), and we're still aiming to land v0.9.0 as the next stable :latest release ready for general public use.

Some recent posts / spec announcements related to the upcoming release:

• https://docs.sweeting.me/s/archivebox-plugin-ecosystem-announcement
• https://github.com/ArchiveBox/abx-spec-behaviors
• https://docs.monadical.com/s/1BvXxNKwT