# Releasing Recess
---

## Reacurring Problems
- Breaking minor updates have affect team velocity and blocked product teams

## Objective
Create a release cadence that's predictable.
Create a system where design/engineering have a
- clear understanding of what versions are avaliable
- what's included in each version

What are the problems that recess is trying?

Define what the outputs of recess are.
- Documentation (UI documentation, design documentation)
- Components
- Design Tokens
- Design assets (sketch, icons, logos, illustrations, etc)
-

### Asset Delivery
- code -> NPM/maybe a cdn?
- fonts/images/css -> delivery via cdn
- Deliver recess-styles via cdn
- design tookits

Ideas/Questions
- Move to a independent component versioning system? (bit.dev)
- Implement status/upcomming features
- Generally, how do we communicate better changes, plans, etc

## Release Cadence

Two options

### Continous Release (current)

Blend a centeral team of developers with more distributed/active contributor community

#### Pros
- Narrow focus per release
- Constant flow of small adjustments and upgrades
- Permit core develpers a lot of leverge over direction

#### Cons
- More likely to break and fix small things constantly
- Rapid iteration disconnects designer/product participation
- Only code docs are part of the process because of loose designer participation
- Design assets/docs drift from code implementaion over time
- Code library is tightly coupled with product teams and can block product development
- Can suffer from long term vision and direction

### Release by Increment

Characterized by regular minor releses on a sprint cadence

Pros
- More likley to support multi-disciplinary teams that include dev, product, design, etc
- More likley to synchronize code and design assets/docs. Docs ahave more design guidence
- Tend to be less coupled to ongoing product work. Regular minor releases offer adopters flexibility when and how to upgrade weighted against other priorities

### Mixing the two

### Hot fixes
We seem to have a lot of these and our "continous" release process seems to be made up of a lot of hot fixes.

This causes work disruption for both the recess team and the product team that needs to get the fix out.

### Long term release cycles

Feels somewhat like the concept of the tick-tok cycle.

Larger cycles are a combination of smaller releases with promoted major changes that are associated with a high level objective (accessibility, colors, motion, navigation, etc).

Deliver changes/upgrades of significant value.

### Sprint
1. Sprint/Increment based release cadence
- With hotfixes
2. Continous Delivery

## Versioning

### Problem

Designers are often unaware of what's avaliable to developers. View recess as v4/5 and don't have more modular versioning

> Designers want the latest. Developers balance tradeoffs of new quality with scale and maintenance. Systems should clean up that conversation.

**Use SEMVER**

Identify what is versioned
- Is the library versioned
- Are components versioned
- Are design assets versioned

Teach designers semver and version things with semver?

### Version library or components

#### Component Versioning
- More targeted and consistent with continuous delivery
- Easier communication around upcoming changes
- More consistent with a distributed model

After determining how/what/why we version and how we release, we should determine how we track work to be dcone for any given release

**Establish a routine for recording and funneling breaking changes away from feature updates/fixes so the don't get in the way of regular work**

### Deprecating/End of Life

How do signal a feature/component/prop is to be discontinued?

**Note: Need metrics for determining usage**

Define a process for communicating and deprecating a component, and document this out.

Establish a pertictable time period for deprecation, and a defined process.

1. Communicate intent via regular channels. Consider a blog post.
2. Decide on a timeline.
3. Add a notice to docs.
4. Run commands on the repository per package.
5. Communicate one last time.
6. Delete it from the repository!

### Aligning Versions of Code, Doc, Design

Code and docs are currently heavily coupled. IF we want to host non-engineering docs, we should think of decoupling docs with code.

Don't want to release code every time we release docs.

**Important**: Maintain previous versions of docs.

Create a consistent pattern of how to publish and host old doc versions

Example: Maybe `.com/` is for the latest, and `.com/V4.x.x` is for previous versions.

#### Versioning design assets

1. Version design assets in a manner that's evident to designers applying them.
2. Reveal versions of code in a manner that's obvious to developers.
3. Align asset versions with their code counterparts.

Create versioned symbol assets for design?
Create sketch libraries for individual components that are versioned independely?
Link those with indepenedly versioned components

#### Design tokens versioning

Potentially version design tokens?
- Host these in seperate sketch/code libraries
- Document and consume?