search

JDRF / design-system

JDRF Design System
http://jdrf.github.io/design-system
MIT License
14 stars 19 forks source link

Versioning #389

Open patrickmckowen opened 7 years ago

patrickmckowen commented 7 years ago

@mrbobbybryant @fuhton Noah,

I'd like to combine the convo I'm having with Noah over email and Bobby over Trello.

This was Noah's latest comment:

Ideally it’d be great if it was hosted on a CDN, alternatively though, we could automatically pull it into the build process from Github based on a release tag. You’re right, though, that this would mean we wouldn’t necessarily have an opportunity to test each new version. If the version numbering is such that we can safely assume a minor version change contains no breaking changes, then we could say we only automatically consume changes on the same major version number. So once the code reaches 1.0.0, we’d only consume 1.x, but if/when 2.0.0 is released, it’d have to be manually updated in the build since we assume version 2 contains breaking changes.

Thoughts?

patrickmckowen commented 7 years ago

We will need an alternative way to consume changes without relying on a build process because JDRF works with vendor's with all levels of developer ability and platform limitations.

mrbobbybryant commented 7 years ago

@pmmck Talking with Nick the plan was to always be using semantic versioning. http://semver.org/

So for example the latest changes to the library were minor bug fixes and admin tasks, so that was handled with a Patch version.

When we add in the new Date Mask, that will be a new feature that DOES NOT contain any breaking changes. That would be a Minor Release. i.e. 0.0.2 would become 0.1.0.

Please let me know if this works for you. If so we can close out this ticket, and move forward with this process.