mirror of
https://github.com/ArchiveBox/ArchiveBox.git
synced 2026-04-25 17:16:00 +03:00
[GH-ISSUE #1526] Information: About the v0.8.x-rc pre-release versioning #3921
Labels
No labels
expected: maybe someday
expected: next release
expected: release after next
expected: unlikely unless contributed
good first ticket
help wanted
pull-request
scope: all users
scope: windows users
size: easy
size: hard
size: medium
size: medium
status: backlog
status: blocked
status: done
status: idea-phase
status: needs followup
status: wip
status: wontfix
touches: API/CLI/Spec
touches: configuration
touches: data/schema/architecture
touches: dependencies/packaging
touches: docs
touches: js
touches: views/replayers/html/css
why: correctness
why: functionality
why: performance
why: security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ArchiveBox#3921
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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!
@pirate commented on GitHub (Sep 26, 2024):
Ah whoops, I didn't realize
0.8.0-rc.1was 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.2but 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-pkgrGiven 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?
@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.
@pirate commented on GitHub (Sep 26, 2024):
Ok cool, I updated the release warning header with some more clarification too:
@pirate commented on GitHub (Oct 23, 2024):
FYI I have now adopted the
v0.8.5rc123numbering scheme for tagging minor bugfix builds under each0.8.xpre-release.The RC number at the end gets bumped for small changes/bugfixes, e.g.
v0.8.5rc51comes afterv0.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.xseries is still BETA-only (including all minor semver/rc version bumps), and we're still aiming to landv0.9.0as the next stable:latestrelease ready for general public use.@pirate commented on GitHub (Nov 12, 2024):
Some recent posts / spec announcements related to the upcoming release:
@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 (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.