docs: Add frontend branching strategy ADR

[arbrandes]

This ADR introduces the concept of "main is unstable" to frontend repositories, from whence alpha packages will be published semantically to NPM.

Parent issue: #96

[arbrandes]

I'm not married to "alpha". It could be "main", or "next", or anything else, really (as long as every frontend app repo follows the same pattern, of course).

[holaontiveros]

So just to be sure I get this right @arbrandes

• Main becomes not prod ready, and is discouraged to use it directly on prod
• There will be branches for something specifcally "stable" (n.x) (1.x, 2.x)

Now, how or were are we going to track what's compatible with which edx-platform version?

[arbrandes]

@holaontiveros

• Main becomes not prod ready, and is discouraged to use it directly on prod
• There will be branches for something specifcally "stable" (n.x) (1.x, 2.x)

That's exactly what I'm proposing, yes. (In addition to publishing from main using a prerelease tag such as the one we have now.)

how or were are we going to track what's compatible with which edx-platform version?

Good question.

It begins with this ADR. Prior to each release we'll announce which versions of things will work with that release. So the announcement would be the source of truth.

One potential de facto source of truth could be frontend-template-site. Whatever is in its package.json is what that release expects. (We would be tagging frontend-template-site with release/verawood.1, etc.)

And obviously Tutor itself, while downstream, would be de facto documentation.