Skip to content

sandbox: add versioning and version history checking #980

Closed

Description

@josephjclark

See parent issue and lightning implementation for details.

I think the work here is:

  • Add (fix, update, merge) a version hash algorithm
  • Add some kind of compare function to Project to compare it to another project
  • Actually there are two comparisongs:
    • Are these projects identical? That means: check all the workflows and see if anything is different
    • Have these projects diverged? That means: check the histories to ensure they have a common root (probably the most recent version in the target is included somewhere in the history of the source)
  • Are there any top level project props that get counted in versioning?
  • Use versions to detect whether we can safely checkout another project onto disk
  • Use versions to tell whether its safe to pull

Note that versions don't give any diffing support: if we want diffing we have to add it explicitly (we should be able to use a similar approach what CLI deploy already uses)

This issue is to add support to Project and all relevant CLI commands (it might need breaking up into an epic)

Activity

  1. moved this from New Issues to Product Backlog in Coreon Sep 1, 2025
  2. moved this from Product Backlog to Ready in Coreon Sep 2, 2025
  3. josephjclark commented on Sep 22, 2025

    @josephjclark
    CollaboratorAuthor

    Right now a Project doesn't have a version. So if you compare two projects and the only difference is that one has added a collection, it'll count as no difference. That means either we need a project version hash, or we need special diffing logic for Projects

  4. josephjclark commented on Oct 16, 2025

    @josephjclark
    CollaboratorAuthor

    It's a conflict if:

    The current version hash of the target is NOT present in the version history of the source

    Note that Lightning mostly controls version history and the CLI doesn't support it at all yet.

    When we implement openfn project fork, the CLI needs to set the initial history of the new fork to be the base version. That gives us a reference point for when we merge later.

  5. josephjclark commented on Oct 20, 2025

    @josephjclark
    CollaboratorAuthor
    Workflow.canMergeInto(target):
    

    Return true if the current workflow can be merged into the target workflow without losing any changes.

    We ask the SOURCE if it is compatible with the TARGET

  6. linked a pull request that will close this issuefeat: workflow merge compatibility #1075on Oct 20, 2025
  7. moved this from Ready to DevX Backlog in Coreon Dec 5, 2025
  8. self-assigned this
    on Feb 10, 2026
  9. moved this from DevX Backlog to Ready in Coreon Feb 10, 2026
  10. moved this from Ready to Done in Coreon Feb 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

  • Status
    Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions