Make it possible to test in "development" scenario

[yarikoptic]

where we would have all development versions of pynwb/hdmf/matnwb so developers could check it out and know that upcoming release does not introduce any regressions. Could be done via just having custom deployment and publishing to development branch instead of main.

[jwodder]

@yarikoptic I'm unclear on how you want this to work/be set up. Are you saying that the results of tests against dev dependencies should be saved to a development branch? What exactly do you mean by "custom deployment"?

[yarikoptic]

@yarikoptic I'm unclear on how you want this to work/be set up. Are you saying that the results of tests against dev dependencies should be saved to a development branch?

yes

What exactly do you mean by "custom deployment"?

I just thought that it should not reuse the same instance/clone (/home/dandi/cronlib/dandisets-healthstatus on drogon) but to have its own .

the tricky part is that code is also in the master branch, so for clean setup we would likely either need to

• S1: separate code into a dedicated dandisets-healthstatus-tools, include as submodule as we did awhile back for https://github.com/dandi/dandi-api-webshots-tools, include as submodule in both branches
  • pros: can allow easier for two completely independent deployments, easier to parallelize without fixing fuse/fsspec
• S2: not bother with branches. have results/ and results-development/ and just populate corresponding folder . But then we would need to also tune README.md to
  • include only the summary section for each of the two results: "Released versions", "Development versions"
  • have detailed reports within each of the directories README.md and point to them from that top level README.md.
  • pros: would provide better overview from a single README.md, no need to swap branches etc.

I tend to like S2 more. WDYT @jwodder ?

[jwodder]

@yarikoptic I prefer S2 as well.

[yarikoptic]

#43 would be particularly useful here since then we could interleave or even possibly run in parallel development and released versions testing without waiting for a complete sweep to finish.