Deploy stable and dev versions of the site
Closed this issue · 7 comments
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
A similar structure to the TLG catalog would also help with adding some snapshot tests #26
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
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).
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.
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.
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.
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.