Skip to content

Proper versioning #232

Open
Open
Proper versioning#232
Labels
enhancementNew feature or requestfeaturehelp wantedExtra attention is neededpackaging

Description

@jinsun-yoo
jinsun-yoo
opened on Oct 26, 2026

Problem

pyproject.toml hard-codes version = "1.0.0". That version is already on PyPI from the old pypi branch, and PyPI won't accept it again.

Task

  • Add setuptools-scm to [build-system].requires, pinned to an exact version.
  • Declare the version as dynamic (dynamic = ["version"]), remove version = "1.0.0", and add [tool.setuptools_scm].
  • Expose chakra.__version__ from the installed metadata: importlib.metadata.version("mlc-chakra").
  • Builds of untagged commits get a dev version locally. Those are never published.

Acceptance criteria

  • A wheel built at tag vX.Y.Z has Version: X.Y.Z in its metadata. Evidence: the Version: line from the wheel's metadata.
  • No file holds a hand-edited version. Evidence: PR link.
  • python -c "import chakra; print(chakra.__version__)" prints the installed version. Evidence: CI log.

Depends on

The rename (above), and the protobuf pin (#195), which also edits [build-system].requires.

Activity

  1. jinsun-yoo
    added
    enhancementNew feature or request
    help wantedExtra attention is needed
    feature
    packaging
    on Oct 26, 2026

  2. winstonliu1111 commented on Oct 26, 2026

    @winstonliu1111
    winstonliu1111
    on Oct 26, 2026
    Contributor

    @theodorbadea is this something within our scope of work?

  3. theodorbadea commented on Oct 27, 2026

    @theodorbadea
    theodorbadea
    on Oct 27, 2026
    Contributor

    2. @theodorbadea is this something within our scope of work?

    Yep, it s in scope.

    Jinsun, I would propose a slightly different approach so please take a look on the following:

    • Tags for version instead of VERSION and, if my reading of the diagram is correct, there is a risk of drift: release has commits that do not go on main ("Version bump 1.0.x"). Tags with setuptools-scm sets the version so version takes it from the metadata. Moreover, this CI/bot thing bneen previously explored in Adds semantic versioning and release publishing #39 and reverted;
    • release branches should, IMO, only allow fast forwarding so that the hash pointer is moved without creating a merge commit (release stays exactly as main at some point in history);
    • changelogs and RNs can be taken from PR titles automatically by github;
    • pypi trusted publishing just needs enabling from the owner of the mlc-chakra project

  4. jinsun-yoo commented on Oct 27, 2026

    @jinsun-yoo
    jinsun-yoo
    on Oct 27, 2026
    ContributorAuthor

    Theo,
    Thanks for the valid points. Yes, you are right. I agree that release branch should not drift from main, and that it should not have extra commits / we should stick to hash pointers, et.c

  5. theodorbadea
    added a parent issue on Nov 1, 2026

  6. theodorbadea commented on Nov 1, 2026

    @theodorbadea
    theodorbadea
    on Nov 1, 2026
    Contributor
    1. @theodorbadea is this something within our scope of work?

    Yep, it s in scope.

    Jinsun, I would propose a slightly different approach so please take a look on the following:

    • Tags for version instead of VERSION and, if my reading of the diagram is correct, there is a risk of drift: release has commits that do not go on main ("Version bump 1.0.x"). Tags with setuptools-scm sets the version so version takes it from the metadata. Moreover, this CI/bot thing bneen previously explored in Adds semantic versioning and release publishing #39 and reverted;
    • release branches should, IMO, only allow fast forwarding so that the hash pointer is moved without creating a merge commit (release stays exactly as main at some point in history);
    • changelogs and RNs can be taken from PR titles automatically by github;
    • pypi trusted publishing just needs enabling from the owner of the mlc-chakra project

    needs slight adjustments since this does not facilitate new version on each merge to main, probably need to release directly for main for this behavior

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestfeaturehelp wantedExtra attention is neededpackaging

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions