Packages: update versioning and release process

[dprokop]

@ryantxu @torkelo

This PR introduces updated Readmes that summarise guidelines about packages versioning and releases. Also, ALPHA notices are added to every package's Readme.

---

I have been thinking recently about the approach to versioning packages. This seems to be slightly tricky, especially that we have some experience now with loads of versions pushed to npm.

Here are my thoughts:

1. Packages' version should ALWAYS reflect current Grafana version
2. We should stop using alpha prerelease id in every version of packages. I think having an an explicite warnings about packages being in ALPHA state until further notice is sufficient. Having alpha in every version on npm is making managing versioning more complicated than it should be and it doesn't bring us any value and it's a pain to say which version of package corresponds to which version of Grafana.
3. We should be publishing packages under 3 different dist-tags on npm:
   • latest - version that is released with latest stable Grafana, i.e. 6.2.5
   • next - version that is released with current Grafana prerelease, i.e. 6.3.0.beta.1
   • canary - version that is released directly from master on every merge, i.e. 6.4.0-pre-bbc3e10b. My main motivation for canary is that master isn't actually the next version. It's a possible next version, depending on the commits that's gonna be cherry picked to the release branch. Also, what is very important, lerna.json version on master should always be the same as in package.json, meaning it's the next major/minor i.e. 6.4.0-pre. The pre doesn't seem like semantic versioning, but as long as we are consistent, this should not be an issue. Grafana doesn't strictly follow semver anyways.

---

So, some action points if this is going to be merged and followed:

• Update scripts/circle-release-next-packages.sh to publish to canary dist-tag instead of next:
  • Either introduce packages:publishCanary script
  • or use yarn packages:publish --dist-tag canary --yes in the script
• Sync with Packages: update package.json files  #18173 (update versions to 6.4.0-pre)
• Next Grafana release will include packages release as well. Depending whether its gonna be beta.2 or stable, we should publish to npm with version corresponding to Grafana version. This is introduced in eb32fe5
• Grafana Release Guide should be updated with new additional step that would describe the process or redirect to this guide. I suggest that you @ryantxu assist anyone who's gonna do the release
• Since there are a lot of versions published to npm already I thought it would be wise to cleanup the history there a little bit. But, if we skip adding alpha to every version, and follow Grafana's versioning, I think we should be fine with those early versions being published on npm. We can ask them to remove some of them later on.
• We should consider publishing from master (canary release according to ^^) to different registry than npm and maybe treat npm as a source of packages released with Grafana. This is described in Packages: versioning and releases #18038 (comment) . Thanks to that we could avoid having a lot of noise in our npm history. We don't have access to GH package registry yet.

[torkelo]

Looks good!"

[ryantxu]

Looks good -- I'll wait for you to get back to pull the trigger :)

[dprokop]

@ryantxu @torkelo can u review one more time, pushed some commits there with script to release next/latest versions when releasing Grafana.

[xlson]

LGTM!

[ryantxu]

LGTM too!