@primer/react starting version

[siddharthkp]

With interest from more applications, and memex using primer/react in production, we will soon have multiple apps using primer/react.

With the new package name @primer/react, do you think it's a good time to prioritise stability and limit the number of breaking changes we get, it feels like a clean point in the timeline for a decision like this.

We can start with @primer/react 1.0.0 and batch our breaking changes to a major version - say once a quarter. We can still introduce new components and change APIs as we learn more, but do it in a backward compatible way that doesn't break any production apps when they upgrade to a new minor version. (for example: new components as drafts; and API changes to existing components that don't break the current API)

If y'all think we're not ready and don't want to get slowed down with backward compatibility just yet (i have my doubts as well), we can start at @primer/react@34 as only a name change from @primer/components

[colebemis]

A couple thoughts here:

• It feels like we've built a lot of momentum in the past month and I except that we'll want to release quite a few more breaking changes before we start to prioritize stability and backward compatibility. If we do want to reset the version number, I'd vote that we reset it to 0.1.0 instead of 1.0.0 to indicate that the library is not stable yet.
• Would resetting the version number cause problems since we already have a lot of git tags?

[siddharthkp]

I except that we'll want to release quite a few more breaking changes before we start to prioritize stability and backward compatibility.

That's fair. We don't have to take this chance now, we can do it later as well

Would resetting the version number cause problems since we already have a lot of git tags?

I'm not really sure, haven't done this before.