[GH-ISSUE #1526] Information: About the `v0.8.x-rc` pre-release versioning

kerem commented

2026-03-01 14:47:10 +03:00

Owner

Originally created by @mAAdhaTTah on GitHub (Sep 26, 2024).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1526

This is partially a documentation request, partially a question/flag on versions.

Right now, I'm running one of the 0.7.x versions because, as I understand it, 0.8.x is beta. I've been a little thrown though, as each RC also increments the minor version (going from 0.8.0-rc to 0.8.1-rc to 0.8.4-rc). My understanding of semver is this should be more like 0.8.0-rc.1, 0.8.0-rc.2, etc. until the 0.8.0 stable release.

Given that, what do you plan to release as the stable version in the 0.8.x line? Will it be an 0.8.x without the -rc suffix? 0.9? Something else?

Thanks!

Originally created by @mAAdhaTTah on GitHub (Sep 26, 2024). Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/1526 This is partially a documentation request, partially a question/flag on versions. Right now, I'm running one of the 0.7.x versions because, as I understand it, 0.8.x is beta. I've been a little thrown though, as each RC also increments the minor version (going from 0.8.0-rc to 0.8.1-rc to 0.8.4-rc). My understanding of semver is this should be more like 0.8.0-rc.1, 0.8.0-rc.2, etc. until the 0.8.0 stable release. Given that, what do you plan to release as the stable version in the 0.8.x line? Will it be an 0.8.x without the -rc suffix? 0.9? Something else? Thanks!

kerem

2026-03-01 14:47:10 +03:00

closed this issue
added the
why: functionality

expected: next release

why: security

why: performance
labels

kerem commented

2026-03-01 14:47:11 +03:00

Author

Owner

@pirate commented on GitHub (Sep 26, 2024):

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?

@pirate commented on GitHub (Sep 26, 2024): 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?

kerem commented

2026-03-01 14:47:11 +03:00

Author

Owner

@mAAdhaTTah commented on GitHub (Sep 26, 2024):

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.

@mAAdhaTTah commented on GitHub (Sep 26, 2024): 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.

kerem commented

2026-03-01 14:47:11 +03:00

Author

Owner

@pirate commented on GitHub (Sep 26, 2024):

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

@pirate commented on GitHub (Sep 26, 2024): Ok cool, I updated the release warning header with some more clarification too: <img width="1216" alt="image" src="https://github.com/user-attachments/assets/58b64104-b850-4351-9cdb-bfcb13352146">

kerem commented

2026-03-01 14:47:12 +03:00

Author

Owner

@pirate commented on GitHub (Oct 23, 2024):

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.

@pirate commented on GitHub (Oct 23, 2024): 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](https://github.com/ArchiveBox/ArchiveBox/releases) 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.

kerem commented

2026-03-01 14:47:12 +03:00

Author

Owner

@pirate commented on GitHub (Nov 12, 2024):

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

@pirate commented on GitHub (Nov 12, 2024): 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

kerem commented

2026-03-01 14:47:12 +03:00

Author

Owner

@pirate commented on GitHub (May 5, 2025):

Some recent news announced here: https://github.com/ArchiveBox/ArchiveBox/issues/191#issuecomment-2848370416

@pirate commented on GitHub (May 5, 2025): Some recent news announced here: https://github.com/ArchiveBox/ArchiveBox/issues/191#issuecomment-2848370416

kerem commented

2026-03-01 14:47:12 +03:00

Author

Owner

@pirate commented on GitHub (Dec 29, 2025):

ok 0.9.0 is shaping up to be pretty awesome, it's got tons of much-requested features including full recursive crawling support e.g. --depth=4, and bultin puppeteer support so we no longer need to launch chrome 5 times just to archive one page.

@pirate commented on GitHub (Dec 29, 2025): ok 0.9.0 is shaping up to be pretty awesome, it's got tons of much-requested features including full recursive crawling support e.g. `--depth=4`, and bultin puppeteer support so we no longer need to launch chrome 5 times just to archive one page.

kerem referenced this issue

2026-03-01 17:56:15 +03:00

[GH-ISSUE #903] Singlefile not working in docker-compose on arm64 (M1 Macs, RPi 4, etc.) #2072

kerem referenced this issue

2026-03-14 23:35:21 +03:00

[GH-ISSUE #903] Singlefile not working in docker-compose on arm64 (M1 Macs, RPi 4, etc.) #3582

Rows
Columns

[GH-ISSUE #1526] Information: About the v0.8.x-rc pre-release versioning #903

[GH-ISSUE #1526] Information: About the `v0.8.x-rc` pre-release versioning #903