Ceylon module repository lacks atomic rollback after schema-breaking dependency upgrade

Resolution for Atomic Rollbacks

Since Ceylon 1.3.3 lacks native transaction boundaries for repository mutations, atomicity must be implemented at the filesystem level. The most reliable pattern is symlink switching combined with versioned subdirectories.

Validated Repository Layout Patterns

To prevent partial updates and enable crash-safe rollbacks, avoid mutating a live directory. Instead, use one of the following structures:

• Versioned Subdirectories: Store each repository state in a unique directory (e.g., /repo/v1/, /repo/v2/). A symlink (/repo/current) points to the active version. To upgrade, populate v2 and atomically update the symlink.
• Shadow Repositories: Maintain a complete mirror of the active store. Deploy the schema-breaking upgrade to the shadow repository, validate it, and then swap the active pointer.

Assumption: This approach assumes the underlying filesystem supports atomic rename() operations for symlinks (standard on most Unix-like systems). On network filesystems (NFS), this behavior may vary and requires local verification.

Deterministic Manifests via ceylon resolve

The ceylon resolve --verbose command provides a deterministic view of the dependency graph. You can script this to create a pre-mutation snapshot:

# Capture current resolution state
ceylon resolve --verbose > manifest_pre_upgrade.txt
# Generate hash for integrity check
sha256sum manifest_pre_upgrade.txt > manifest_pre_upgrade.sha256

If a deployment fails, this manifest allows the pipeline to verify exactly which versions were present before the mutation, facilitating a precise rollback to the previous state.

Incremental Recompilation Strategy

To maintain servability during a schema-breaking upgrade, follow these steps:

1. Parse the --verbose output to identify all modules that depend on the upgraded library.
2. Recompile only those affected modules against the new version using ceylon compile.
3. Deploy the new .car files into a new versioned subdirectory.
4. Switch the symlink to the new directory only after all affected dependents are compiled and present.

Note: Because the Ceylon resolver does not support side-by-side major versions of the same module ID, any module not recompiled against the new schema may still throw ClassNotFoundException or linkage errors at runtime if it is invoked.

Verification and Safety

Verify the switch using a simple import test or by checking the symlink target:

# Verify active path
readlink /repo/current
# Verify resolution
ceylon run --verbose test-module

Missing Diagnostic: Are you deploying to a local disk or a network-attached storage (NAS) volume? The choice of filesystem significantly impacts the reliability of the symlink swap.