Before next release: bring main's 0.2.0 changes into develop and fix the setup guide's broken install link #282

Activity

1. abrahamnash

   assigned

   umeradl

   on Oct 26, 2026
2. abrahamnash

   added

   bugSomething isn't workingSomething isn't working

   documentationImprovements or additions to documentationImprovements or additions to documentation

   on Oct 26, 2026
3. umeradl commented on Oct 26, 2026

   

   umeradl

   on Oct 26, 2026

   Last edited by umeradl

   Member

   More actions

   Thanks @abrahamnash. The broken link and the rollback risk are both real. One correction to the framing first, because it changes the fix.

   There is no "DevNet 2.0" release. dincli 0.2.0 (2409664, 19 Aug) is the CLI for DevNet 1.0, the contracts currently live on OP Sepolia, and it was released directly on main. develop's dincli targets the newer contracts, which aren't deployed anywhere yet. So develop shouldn't take main's 0.2.0 bump or its dist/ wheels, and develop's setup guide shouldn't send people to the main wheel either: develop's docs describe develop's code, which doesn't work against the live DevNet 1.0 contracts.

   Nothing needs to come from main

   The main-only fixes that matter were already brought over to develop (by @Santiagocetran and @umeradl): bridge-eth, read-din-per-eth, the connect-wallet / connect-demo-wallet split, CID verification on IPFS downloads, chain-id validation, the Python 3.12 floor, click as an explicit dependency, LICENSE, and .env.example.

   What remains on main only is DevNet 1.0 state that develop doesn't need: the 0.2.0 bump and dist/ wheels, the accounts.json packaging exclusion (on develop the file is tracked and holds only the Hardhat/Anvil default dev keys, and connect-demo-wallet needs it in the wheel), the CPU/CUDA requirements-*.txt split (develop uses per-role cache_model_0/requirements/ files), dindao.md, and similar. So no main → develop merge or porting is needed; we keep the usual develop → main flow.

   What's left

   1. Fix Documentation/public/setup.md on develop: install from source (git clone + pip install -e .), and drop Option B (dist/ isn't a Python project, so it can't build). Add a note that participants joining the live DevNet 1.0 should follow main's setup guide and its 0.2.0 wheel. This edit is already a row in task_061026_21 Part E, which points at the main wheel. I'll change that row to "install from source" so the two don't conflict.
   2. Move develop's version above main's: 0.3.0.dev0 now, then 0.3.0 when develop's contracts are deployed, so main never goes back from 0.2.0 to 0.1.0.
   3. At release, merge develop into main so that main's files end up exactly develop's. A plain merge isn't enough: since the branches split in May, a dry run shows 22 conflicting files, and git would also silently keep main's version of 9 non-conflicting files (e.g. MANIFEST.in, the deleted cache_model_0/requirements.txt, dindao.md, dist/dincli-0.2.0-*). Instead:

      git checkout main
      git merge --no-commit --no-ff develop
      git read-tree -u --reset develop   # main's files = develop's files
      git commit
      git diff develop main --stat       # must be empty

      This keeps main's history and makes its content identical to develop.

   Dropping from the original suggestion: merging main into develop, and a GitHub Release asset or an @v0.3.0 tagged install link for develop. There's nothing to release from develop until its contracts are deployed. Tagging is tracked separately.

   Going forward, agreed: fixes land on develop first, so main doesn't drift ahead again.
4. abrahamnash commented on Oct 29, 2026

   

   abrahamnash

   on Oct 29, 2026

   MemberAuthor

   More actions

   Agreed with this framing. 0.2.0 is the DevNet 1.0 CLI released on main, so develop's setup guide shouldn't point at main's wheel. Until DevNet 2.0 ships with its own release, develop should use the install-from-source route (as #294 does), and anyone joining the live network should use main's guide and the v0.2.0 release.