Uh oh!
There was an error while loading. Please reload this page.
chore: open the 2.0.0-beta line on develop - #321
Merged
Conversation
main now carries the 1.x stable line and develop carries 2.x beta, so develop should not inherit main's 1.1.0 version. Bump it to the first 2.0.0 pre-release instead. Uses each ecosystem's canonical pre-release form: 2.0.0b0 (PEP 440) in buzz/__init__.py, since flit reads it as the package version, and 2.0.0-beta.0 (semver) in package.json. Documents the two release lines in the README's contributing section, next to the backport-label instructions, so contributors know which branch to target. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TqhZUMguWUR63DcCdUBP9W
harshtandiyaforce-pushed
the
claude/develop-2-0-0-beta-bump
branch
from
August 7, 2026 12:45
8de3514 to
baef51fCompareFrappe parses each app's __version__ with semantic_version.Version in its daily update check (frappe/utils/change_log.py), and that parser rejects the PEP 440 form "2.0.0b0". Use "2.0.0-beta.0" instead: it is valid semver and pip normalises it back to 2.0.0b0, so packaging is unaffected and package.json now matches. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
harshtandiya
marked this pull request as ready for review
August 10, 2026 10:26
Uh oh!
There was an error while loading. Please reload this page.
Contributor
Greptile SummaryThe PR opens the 2.x beta development line and documents how changes flow between development and stable branches.
Confidence Score: 5/5The PR appears safe to merge with no actionable defects identified. The Python and npm version metadata use a compatible prerelease value, and the new contributor instructions match the implemented post-merge backport workflow.
|
| Filename | Overview |
|---|---|
| buzz/init.py | Updates the application version to the 2.0.0 beta prerelease form accepted by the relevant Python packaging and Frappe version consumers. |
| package.json | Updates npm package metadata to the corresponding canonical semantic-version prerelease. |
| README.md | Adds branch-targeting and backport instructions consistent with the repository's backport workflow. |
Reviews (1): Last reviewed commit: "chore: use the semver pre-release form f..." | Re-trigger Greptile
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion to #320. That PR cuts 1.1.0 on
main; this one opens the 2.x beta line here sodevelopdoesn't inherit a 1.x version.Split of the two lines:
main= 1.x stable,develop= 2.x beta.Changes
buzz/__init__.py:__version__→2.0.0b0package.json:version→2.0.0-beta.0README.md: a short Branches subsection under ContributingWhy the two version strings differ
They're the same version in each ecosystem's canonical pre-release form:
2.0.0b0is the PEP 440 normalised form. flit reads__version__as the package version (dynamic = ["version"]inpyproject.toml), and writing2.0.0-beta.0there would rely on flit normalising it — some flit versions error on a non-normalised version instead.2.0.0b0avoids the question.2.0.0-beta.0is the semver form npm expects;2.0.0b0is not valid semver.Worth a sanity check on your side: I couldn't run flit here (
flit_coreisn't installed in this environment), so the PEP 440 reasoning is frompackaging, which normalises2.0.0-beta.0→2.0.0b0. Abench build/ editable install on a real bench would confirm it.README
The new subsection sits directly above the CI section and states which branch to target, that a merged PR gets a
backport mainlabel to reach the stable line, and that 2.x-only work stays here unlabelled. It goes next to the existing contributing instructions because that's where someone deciding their base branch is already looking.Note the install instructions further up already say
bench get-app --branch main, which stays correct under this split.Sequencing
Independent of #320 — no shared files land on both branches, so either can merge first. And like #320, this one must not get a
backport mainlabel.