Skip to main content

Maintainership

Guidelines for Development on Gesso Packages​

This document outlines the guidelines for development on Gesso packages, covering releases, roadmap, dependency management, breaking changes, bug tracking, feature requests, contribution, documentation, and security.

Releases​

All packages are versioned and published automatically using a tool called Semantic Release.

What is Semantic Release?: Basic guide to Semantic Release

Follows Semantic Versioning: https://semver.org/

Release Schedule​

Major: January / July (Every 6 months)

Minor: Anytime, but at least every 2 weeks

Patches: Can be released as needed. Preference to frequent small releases

Dependency management​

Peer dependencies:

  • Support current and one version back of react
  • May support additional version at the team's discretion

Acro support of APIs will follow suit of the vendor.

IE: BigCommerce drops support, Gesso will follow suite.

Breaking changes​

Introductions of breaking changes must be deprecated in the minor version

Including deprecation annotations, and version that the deprecation will be removed

When dealing with deprecation from 3rd party the Gesso team may have to make deprecation off schedule.

Deprecated code must live through an entire major version

IE: If deprecated in v2.1, the deprecated code can't be removed till v4.

Deprecations are a priory, they will trigger linting errors and must be attended to immediately.

MR releases will be blocked by and usage of deprecated code.

In some cases where the deprecation comes from third party and we are blocked by it being completed upstream the team should mark it in code and reference the 3rd parties issue number. If needed the patch should be done by the team and submitted back. There must be a Jira ticket created that references the issue and includes the 3rd parties upstream ticket as to keep visibility.

Bug tracking​

Bugs are tracked on a separate board.

Bugs are highest priority

Bug tickets must follow a specific format which includes:

Specific package and version affected

Environment

Description of the issue, including any error logs

Steps to reproduce, links to project branch where the issue exists

Feature requests​

Feature requests are tracked on a separate board

Team is required to groom feature requests

Assign priority / deny the request

Feature requests must be submitted with a reason

Why do you need it?

Scope for feature requests

Feature request priority will be voted on by the team

Large changes like 3rd party integrations will be manged by the project teams paid for by the client

Contribution​

Contributions are high priority

Must be responded to within a day

Merge requests for contribution from project teams (outside Gesso) are not required to be “perfect” Gesso team will clean up or update code as needed.

Security​

Third-party Packages

Checking for outdated packages

No releases with security issues. These are hard blockers.

Security changes that are breaking can be deploying outside our typical major release schedule

Requires security notices communicated to the teams (using Gesso)

Security meetings with STL’s and Project Leads (use TL weekly on Thursdays adhoc)

Severity scaling IE 1-3 Minor security issues can be address less timely then a major security issue. Major issues MUST be addressed immediately.

Internal Packages

Schedules security review from developers outside Gesso (Fresh eyes)

All server-side tokens are server-side only

Major releases get security reviews before release.

READMES​

What should we required in a readme?

Examples:

  • How to test

  • How to compile

  • How to contribute

  • Seperation of Dev notes vs End user notes

These guidelines provide a framework for development on Gesso packages, ensuring smooth collaboration, versioning, bug tracking, feature implementation, and security across the project.