search

pharmaverse / examples

End to end examples of pharmaverse packages for common safety clinical reporting analyses
https://pharmaverse.github.io/examples/
Apache License 2.0
6 stars 6 forks source link

Deploy stable and dev versions of the site #29

Closed vedhav closed 6 months ago

vedhav commented 7 months ago

When a new feature is introduced in the example it should be easier for us to integrate this change if we maintain a dev version of the site.

Start with updating the DESCRIPTION with min versions of the packages. A good example would be to have a look at the TLG Catalog

vedhav commented 7 months ago

A similar structure to the TLG catalog would also help with adding some snapshot tests #26

bms63 commented 7 months ago

Is there a way to leverage the Description and a .yml file to allow for a dev mode - like we do in admiral and xportr

Or

maybe there is some option here that builds a dev version of the site? https://quarto.org/docs/reference/projects/websites.html#project

pawelru commented 7 months ago

Do you guys see any point in DEV version? I assume end-users are interested in STABLE only. DEV is super useful for development perspective as an integration tests environment but I guess all the respective package developers are doing this anyway elsewhere. For simplicity I would propose to stick with STABLE only (and actually don't introduce this split at all).

bms63 commented 7 months ago

I was thinking as the content grows it might be nicer to view updates on a dev site before releasing to the general public.

I do really sympathize with keeping the site simple as we overdid it a bit in admiral and caused us so many headaches. If the solution is not easy (like one line of code in a file), then I think we should pass on it.

vedhav commented 7 months ago

The biggest benefit of having a DEV version I see is that the STABLE site would be more "stable". By that I mean we would catch any breaking changes before the release and would have time to react and update the STABLE version just as the package with a breaking change is released. Having only a STABLE site would mean that our examples would not work for the time between the release and the time we take to fix the site which is something I would like to avoid. This is rather a low-probability event (pretty much zero if we have snapshot tests and catch the deprecation warnings). So, if the effort to maintain the DEV is higher than us reacting quickly to fix the snapshot test failure that we observe then I think we're good.

rossfarrugia commented 7 months ago

Could be a good team discussion for next call. I'm currently siding with keeping it simple as Pawel suggests for now, but will be interested to hear others input on this.

rossfarrugia commented 6 months ago

OK - we didn't get any further input on this one so rounding it off i'm going to make the call to keep it simple and not add a DEV site. Given the purpose of this and the fact its supported by small % time commitment volunteers, I'm sure our community would understand if ever an example is not imeediately maintained in line with newest package releases. We'll just commit to doing our best here.