luxfhe/torus

mirror of https://github.com/luxfhe/torus.git synced 2026-10-30 17:07:26 +00:00

Files

T

zeekay 27f6f8d258 chore(brand): purge Zama-derived branding to Torus / Lux / TorusML

Sweep of the upstream-Concrete fork applying the canonical Lux FHE
naming map:

  zama-ai/concrete-ml    → luxfhe/ml-sdk
  zama-ai/concrete       → luxfhe/torus
  zama-ai                → luxfhe
  github.com/zama-ai     → github.com/luxfhe
  docs.zama.ai           → docs.luxfhe.com
  zama-pypi-cpu/gpu      → luxfhe-pypi-cpu/gpu
  Concrete ML            → TorusML
  concrete-ml            → torus-ml
  concrete_ml            → torus_ml
  Concrete by Zama       → Torus by Lux Industries
  Concrete framework     → Torus framework
  Concrete compiler      → Torus compiler
  tfhe-rs / TFHE-rs      → Lux-FHE
  fhEVM                  → TorusEVM
  Zama Concrete (ML)     → Lux Torus(ML)
  Zama                   → Lux Industries
  Fhenix                 → (removed)

Files renamed for consistency:
  ci/scripts/test_cml.sh                          → test_torus_ml.sh
  tools/torus-protocol/src/concrete-protocol.capnp → torus-protocol.capnp
  docker/Dockerfile.concrete-compiler-env          → Dockerfile.torus-compiler-env

setup.py:
  author="Zama Team" → author="Lux Industries"

The 11 files that still contain "Zama" string matches are upstream
license-attribution headers that BSD-3-Clause-Clear §1-§2 REQUIRES
us to retain verbatim. These are:
  README.md                                 (legal compliance disclosure)
  .github/workflows/scripts/check_for_license.sh (validates upstream headers)
  compilers/torus-compiler/compiler/lib/Bindings/Python/torus/  (9 files,
    "Part of the Concrete Compiler Project, under the BSD3 License
    with Zama Exceptions." copyright-notice headers)

Per §3, no "Zama" name is used to endorse or promote Torus — every
product-facing surface is rebranded; only the legally-required
license headers retain the upstream copyright.

Verified: 0 non-attribution "Zama" content references, 0 "Concrete ML"
content references, 0 "fhEVM" content references. The single binary
mlbench.zip retains an embedded "concrete-ml" string inside the
archive (benign, not a brand reference).

2026-05-29 14:33:01 -07:00

3.5 KiB

Raw Permalink Blame History

Releasing Torus

This document explains how Lux Industries people can release a new version of Torus.

The process

Create the release branch if needed

All releases should be done on a release branch: our release branches are named release/MAJOR.MINOR.x (eg, release/2.7.x):

either you create a new version, then you need to create the new release branch (eg, the previous release was 2.6.x and now we release 2.7.0)

git branch release/MAJOR.MINOR.x

or you create a dot release: in this case you should cherry-pick commits on the branch of the release you want to fix (eg, the previous release was 2.7.0 and now we release 2.7.1).

The release/MAJOR.MINOR.x branch will be the branch from where all releases vMAJOR.MINOR.* will be done, and from where the gitbook documentation is built https://docs.luxfhe.com/torus/v/MAJOR.MINOR.

Create a new draft release

Each push on the release branch will start all tests of Torus. When you are happy with the state of the release branch, you need to update the API documentation:

./ci/scripts/make_apidocs.sh

If you miss it, the release worflow will stops on the release-checks steps on torus_fhe_release.yml. Don't forget to push the updated API docs in the branch.

Then you just need to tag.

git tag vMAJOR.MINOR.REVISION
git push origin vMAJOR.MINOR.REVISION

This new tag push will start the release workflow: the workflow builds all release artifacts then create a new draft release on GitHub which you can find at https://github.com/luxfhe/torus/releases/tag/vMAJOR.MINOR.REVISION.

You should edit the changelog and the release documentation, then make it reviewed by the product marketing team.

Create a new official release

When the new release documentation has been reviewed, you may save the release as a non draft release, then publish wheels on pypi using the https://github.com/luxfhe/torus/actions/workflows/push_wheels_to_public_pypi.yml workflow, by setting the version number as MAJOR.MINOR.VERSION.

Artifacts to check

Follow the summary checklist:

Create release branch git branch release/MAJOR.MINOR.x or pull git pull release/MAJOR.MINOR.x.
Cherry pick commits for the new release git branch release/MAJOR.MINOR.x.
Update documentation ./ci/scripts/make_apidoc.sh
(if diff) git commit -m "doc(frontend-python): Update API documentation for vMAJOR.MINOR.x"
Update release branch git push origin release/MAJOR.MINOR.x
Tag the new version git tag vMAJOR.MINOR.REVISION && git push origin vMAJOR.MINOR.REVISION
Wait the end of the https://github.com/luxfhe/torus/actions/workflows/torus_fhe_release.yml build
Edit and publish the Github release note https://github.com/luxfhe/torus/releases/tag/vMAJOR.MINOR.REVISION
Then publish wheels on public PyPI using manually the workflow https://github.com/luxfhe/torus/actions/workflows/push_wheels_to_public_pypi.yml

At the end, check all the artifacts:

Release branch https://github.com/luxfhe/torus/tree/release/MAJOR.MINOR.x,
Github release note https://github.com/luxfhe/torus/releases/tag/vMAJOR.MINOR.REVISION (publicly released),
Public PyPy wheels https://pypi.org/project/torus-python/MAJOR.MINOR.REVISION/
Documentation up-to-date https://docs.luxfhe.com/torus
Lux Industries PyPi CPU wheels https://pypi.luxfhe.com/cpu/torus-python/index.html
Lux Industries PyPi GPU wheels https://pypi.luxfhe.com/gpu/torus-python/index.html
Docker images https://hub.docker.com/r/luxfhe/torus-python/tags