Hi Barry and others, nice to see Dana is still being actively worked on :),

We're using the Emergent Web Server for a course here at the Vrije Universiteit Amsterdam, and in order to extend it we needed to use an older version of Dana, specifically 251. I was able to obtain said version with some URL trickery. However, this leads me to the suggestion of changing how Dana versions are published. I'm aware the GitHub exists with older versions but this doesn't contain the executables to easily create a full install.

Would it be possible to create a page which simply has a directory of all versions (that you can still allow to be downloaded within the capacity of the server hosting this website)?Another option would be to use 'Releases' on GitHub. Oh, also while we are at it, there is the non-trivial side issue which is the Dana documentation. Is it possible to have the docs page adjustable to older versions than Dana, not just the newest?

Thanks,Elvin Alberts

Hi Elvin,

These are some good ideas :-)

Can I check why that version is needed specifically / which features have changed in more recent versions? We generally guarantee to continue to host any Dana versions which are linked from our research entries, to support reproducibility, and it looks like 251 happens to be one of those. We could at least enumerate this list of options all in one place somewhere.

We maintain an up-to-date build of the "rex" web server here which tracks with the current Dana release: https://github.com/barryfp/rex_ws (but you might have a variant of this in mind which has different features).

On documentation, I assume you mean here the Dana API docs rather than the user guide stuff. I think this is a really good suggestion; it's a little trickier to solve but we'll give it some thought. As a potential quick solution, while we think that through, you can generate the API docs locally by running dana docgen in the "components" directory of your installation. This yields a folder called _docs which you could possibly then host at your own server.

Barry

Hey Barry, thanks for the quick response,

You are right in your assumptions, I meant the API specifically. As for the versions of the web server, we were specifically making use of EWS as packaged for our SEAMS artifact paper, since the students in our course make use of exemplars as catalogued on self-adaptive.org. As for the docs solution, I'll be sure to forward that information to the students, thank you.

Considering your 'rex' server though it may be a good idea to create some symbolic link between EWS and it. Then, people who find the artifacts through SEAMS are can more easily extend the work if they're interested in doing so.

Elvin

Ah ok, that's fair, thanks for the clarification. I've just tested that exact EWS package and it operates correctly in the latest Dana version, so I think your students could use that version if they would like to. They'll get some deprecated API warnings during compilation, but we've maintained a stable backwards-compatible API for quite some time so the system still operates correctly.

We'll still aim to action the above suggestions though! :-)

Barry

A quick update on this: we've taken a first attempt at implementing these thoughts, and you can see it at /legacy/ (this page is now linked from the main page instead of the old drop-down selector).

Most of the versions don't have an API reference, but 251 specifically does, and we'll think over how to better maintain legacy API refs more broadly across other selected versions in future :-)

Barry

Hi all :-)

I wanted to say this is a really neat addition for software sustainability over time! Thanks for making it.

jess