# Overview JETLS avoids dependency conflicts with packages being analyzed by [[JETLS environment isolation#On-disk UUID rewriting approach (vendoring)|rewriting the UUIDs of its dependencies and vendoring them]]. This note discusses how to release JETLS, including its vendored dependencies. # Branch strategy - Development branch: `master` - Regular development happens here - Dependencies keep their original UUIDs - Release branch: `release` - Distribution branch for users - Dependencies are vendored with rewritten UUIDs - Includes copies of dependency packages in the `vendor/` directory # Release procedure 1. Check out the `release` branch ```bash git checkout release ``` 2. Merge changes from the development branch[^merge-strategy] ```bash git merge -X theirs master ``` 3. Vendor dependency packages ```bash julia vendor-deps.jl --source-branch=master ``` This script performs the following: - Fetches the latest `Project.toml` from the `master` branch - Backs it up as `Project.toml.bak` - Cleans up `Manifest.toml` - Updates dependencies with `Pkg.update()` - Loads JETLS and collects dependency packages from `Base.loaded_modules` - Copies each package to `vendor/` and rewrites its UUID - Updates `Project.toml` with vendored UUIDs and `[sources]` entries 4. Commit changes ```bash git add -A git commit -m 'release: 2025-11-23' ``` 5. Push to remote ```bash git push origin release ``` [^merge-strategy]: The `-X theirs` option automatically resolves merge conflicts by preferring the `master` branch version. This is necessary because `Project.toml` files are always modified on the `release` branch (with vendored UUIDs), causing conflicts when merging. Since `vendor-deps.jl` fetches and overwrites `Project.toml` from `master` anyway in step 3, these conflicts can be safely resolved by taking the `master` version. Using `git merge` (rather than `git rebase`) keeps the commit history linear for users who update via `git pull`. # Determinism of UUID generation `vendor-deps.jl` generates UUIDs using `uuid5(original_uuid, "JETLS-vendor")`. This is a deterministic hash-based generation, so the same vendored UUID is always generated for the same original UUID. Because of this, UUIDs remain consistent even when vendoring is performed multiple times on the `release` branch. # User installation methods ## Method 1: Directly check out the branch As described in the current README: ```bash git clone https://github.com/aviatesk/JETLS.jl cd JETLS.jl git checkout release ``` ## Method 2: Add as a Pkg app (planned) ```julia pkg> app add https://github.com/aviatesk/JETLS.jl#release ``` With this method, users can run JETLS as a `jetls` command, which is more convenient because then we wouldn't need to specify the path in their IDE configuration. ## UPDATE 2025-11-24 Now that the [[jetls executable app]] is implemented, all recommended installation methods have moved to [[#Method 2 Add as a Pkg app (planned)]]. # Version control plan After officially releasing JETLS, it would be better to create version-named branches like `v0.1.0` for each release, instead of maintaining a single `release` branch. This way, users can install specific versions using `pkg> app add https://github.com/aviatesk/JETLS.jl#v0.1.0`. Note that automatic updates via `pkg> up` would still be impossible, due to the following [[#Constraint cannot register with registry]] constraint. # Constraint: cannot register with registry The current approach of using local `[sources]` with a `vendor/` directory prevents registration of JETLS to the General registry, since packages registered in the registry must have all their dependencies registered there and cannot reference local file paths. Therefore, for now, we continue development on the `master` branch, regularly upstream changes to the `release` branch (or create fresh branches for each version), and update the release branch by running `vendor-deps.jl` each time. Users then directly use the `release` branch via `git pull` or `pkg> app add`.