Only pass public versions to html context

[stsewd]

Had to add a new field to the api response. Should I document the new field in our docs? https://docs.readthedocs.io/en/stable/api/v2.html#version-detail

[stsewd]

I just went ahead and update the docs

[ericholscher]

I think this will be a good approach. @agjohnson was trying to scope it only to .com for now, but I think this should be fine. I'll let him -1 it if he feels strongly.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ericholscher]

I still think this makes sense to merge.

[agjohnson]

I'm not against removing the non-public versions from the list, however this is a deprecation of a feature that we're not sure if any users are using. Users could be using the version list inside their templates for something other than the version list in the build output flyout. We should probably find a way to communicate this deprecation to users. Alternatively, we can expose all projects on a separate context data key, and communicate that the context data key for all versions has moved.

This might be a signal that we could benefit from a more complex data structure being passed into the theme context -- new releases of the theme could use public_versions() instead of the theme context data directly. However, the correct solution is probably to make new versions of the theme not generate a flyout at all.

[stsewd]

Not sure how to communicate the deprecation outside rtd. I mean, we can add a deprecation warning from our extension, but it's going to appear in all the builds that happen inside rtd. Maybe a lot of people don't even know that option exists, it's going to be confusing to see that warning from something they aren't using. We don't have a way to know if they are using that context data outside of our theme.

[humitos]

I'm 👍 with this change.

I understand @agjohnson concerns but I think it's better to be safe here. When we enable PR builders on .com we can't expose private versions to the context. So, I'm thinking that removing them is a good path forward.

Another one could be to remove them only from PR builds, as we are doing with environment variables.

On the other hand, we could add a feature flag to recover the old behavior in case that someone complains about we change this. Instead the other way around (I suspects that no many people -if any- are using private versions from the context).

[stsewd]

I think feature flag is a good idea to keep old behavior if anyone is using it. Are we ok with that? I can add it.

/cc @agjohnson @ericholscher

[ericholscher]

Yea, if it's easy lets add a feature flag, so we don't have to do a deploy if someone complains :)

[ericholscher]

Makes sense 👍