Updating all repos/docs to point at 1.0.0-alpha?

[m8pple]

The usage.pdf in orchestrator_documentation (release 1.3, here) talks about commands of the form:

task /load = "plate_3x3.xml"
task /show

Which matches what I remember.

However, it seems that the most useful branch of the orchestrator is 1.0.0-alpha (see #186), so I switched from development to that.

Then commands started becoming unintelligible, when previous they had worked (or at least been parsed).

After switching to the 1.0.0-alpha branch of the documentation it seems that commands switched to the following format:

load /app = +"ring_test.xml"
show /apps

Given you're doing continuous integration and code reviews, wouldn't it make more sense to have the four main repos (Orchestrator, orchestrator_documentation, orchestrator-dependencies, orchestrator-examples) all default to the same branch? Ideally the development tip, or at least close to the branch that Graeme is using for his heat plate experiments.

[heliosfa]

1.0.0-alpha was meant to be transient, but it’s lifetime has dragged on for several reasons. We are in the process of getting everything merged in.

the intention was to leave Development of all branches in a working state with v2 XML (as we had someone using the old version) until the v4 implementation of the Orchestrator was robust, which it is now.

development on all branches should work together, And 1.0.0-alpha on all branches should work together. It is possible that we have messed up a merge target at some point.

Given you're doing continuous integration and code reviews, wouldn't it make more sense to have the four main repos (Orchestrator, orchestrator_documentation, orchestrator-dependencies, orchestrator-examples) all default to the same branch?

v4 included a significant refactor of a lot of bits of the Orchestrator, which is why we created the alpha branch. Everything will fold down to development in short order.

[m8pple]

Switching to 1.0.0-alpha is becoming fairly critical in terms of getting people using the orchestrator.

I've had questions from our new MSc student about how to simulate and debug applications locally, and I can tell them how to simulate using graph_schema, but can't guarantee that it will then parse in the orchestrator. Using v2 xml is not viable, as we stripped out all of that out after the v3 / v4 discussions, so the simulation tools only support v3 and v4 format.

They are also very interested in IO (as they are doing ML), so I looked into providing simulation support for supervisors, but can't work out which version of the documentation/code to use, and which parts are intended to be supported rather than working right now. For example, if I implement SupervisorType/OnSend as suggested in the documentation then it is not clear whether that works in the codebase, so I might be sending them down a blind alley if I said "this will let you inject data into a graph at run-time". Looking at orchestrator_examples I see examples of supervisors receiving messages, but not sending them.

I could tell them to use externals (which will simulate, mostly), but I think externals are unlikely to be implemented, so they would need two different IO methods - one for v4, and another for the orchestrator's supervisor-based IO.

If you still need to support students working on the v2 stable branch, could you make the 1.0.0-alpha the default branch on each repo? It would make it much less likely to get confused about whether one is on the right branch or not when trying to cross-compare between repos on github.

[mvousden]

I've changed the default branches of the Orchestrator, the examples, and the documentation repos to point to 1.0.0-alpha in each case.