Closed 6293 closed 1 year ago
AluVM will have more languages than just an assembly, and assembly language must develop independently from the VM bytecode (i.e. there may be breaking assembly mnemonic changes, but not breaking bytecode changes). Thus, I think it is desirable to have them as separate repos with potentially different maintainers in the future.
AluRE is just a runtime environment which is much upper layer with less strict requirements; for instance RGB uses AluVM without AluRE providing its own runtime. Most of AluVM uses will ship with their independent runtimes and it will have an independent release cycle.
Holding all of them in the same repo will make milestones, releases and issues, CI and maintainer right management IMO even much more difficult than creating two PRs for AluVM and AluAsm today... Do you agree?
I was a bit frustrated by these situation like https://github.com/AluVM/aluasm/pull/12 where CI fails just because the corresponding PR on aluvm hasn't been merged (locally I run test by cargo test --config 'patch.crates-io.aluvm.path="../rust-aluvm"'
), but you are right.
bugs on aluasm are often caused by aluvm. submitting separate PR is sometimes cumbersome because the PR on aluasm fails until the PR on aluvm has been merged