Updated clone_docs script to only checkout and copy docs w/ latest git tag

[MarnickvdA]

This PR does not solve the feature request to support multiple versions in the docs, but solves the problem of having library releases that are out-of-date with the docs. Docs will be copied based on the latests git tag of each Stryker language version, which would be equal to the latest release.

Relates to #345

[netlify]

✅ Deploy Preview for stryker-mutator ready!

Name	Link
🔨 Latest commit
🔍 Latest deploy log	https://app.netlify.com/sites/stryker-mutator/deploys/635ce767686fae2f7d84a3ee
😎 Deploy Preview	https://deploy-preview-484--stryker-mutator.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[hugo-vrijswijk]

The only thing I'd be worried about is we often make typo fixes, or improve the general documentation on mutation-testing-elements which doesn't always need a new release to be published

[MarnickvdA]

How would you see current and vnext update content with these typo changes? The current docs version would need something to know what it should copy from version control, presumably the latest release tag to prevent new unreleased features from existing in the docs. The vnext version would just copy the docs from HEAD, fixing typos but also possibly introducing unreleased features.

Maybe mutation-testing-elements shouldn't be handled with the same procedure as the Stryker flavours in terms of updating the docs?

[rouke-broersma]

@hugo-vrijswijk I can live with doc fixes not being published right away, should just release more often if it's a problem :D
I think this change would overall be for the better. I would also be happy with a vcurrent and vnext. @nicojs @richardwerkman what do you think.

[richardwerkman]

With the current implementation in this PR I see one issue, what if we release a patch version for an old version? It will be the latest tag but the docs will be outdated. We don't really do patch releases on old versions at the moment. But if we would do this, it would create issues.

About the vNext/vCurrent solution, this would be the best of both worlds. However, we don't have a way of versioning in the UI right now. And if we had we could also support tracing back all versions based on tags. Not just vCurrent.

[rouke-broersma]

@richardwerkman i thought docusaurus already supported versions, biggest issue is that it's a global thing and Stryker versions are not comparable.

Personally don't care for the patch release issue, it's not likely to happen any time soon, and if it does happen we'll change our infrastructure to support it then.

[rouke-broersma]

@nicojs @hugo-vrijswijk @richardwerkman can we all agree that this would be better than what we currently have? Personally I would rather have slightly outdated docs because we didn't perform a new release and thus don't yet incorporate some small fixes, than too-far in the future docs.

[hugo-vrijswijk]

I don't think I agree. It happens pretty often that fixes are added, or docs are improved without the need for a new release. The only reason to want this is for configuration options, and Stryker4s already has a since tag on each config option. Ideally, you could just switch between 'next' and 'stable' versions of the docs if you really want to be sure, which is possible with Docusaurus. But I think by only showing the latest release we lose too much

[rouke-broersma]

Next and stable sounds pretty easy, just use latest commit for Next and latest tag for Stable. Would you agree with that then?