> For the complete documentation index, see [llms.txt](https://sygnal.gitbook.io/sygnal-webflow-components/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sygnal.gitbook.io/sygnal-webflow-components/technical-notes/code-components/marketplace/github-protocol.md).

# Github Protocol

**Sygnal Component Marketplace ( SCM )** uses Github for the storage and deployment of Code Components to subscribing Webflow Workspaces. 

## Branch Structures 

### Integration Branch ( `main` ) 

`main` is the integration branch.  You can do integration testing here, and do deployments to your standard test workspace, it will not affect SCM deployments.  

### Release Branches ( `release/*` ) 

{% hint style="success" %}
Always use a major.minor convention, e.g. `release/0.1` for the branch name. \
Always tag your release using the form major.minor.patch, e.g. `v0.1.4`  
{% endhint %}

{% hint style="warning" %}
The marketplace actions will consider the most current tag to be the current release, based on semver sorting.  Avoid pre-release and build metadata, e.g. `v2.3.8-beta.2` , this is currently unsupported. 
{% endhint %}

Why we use this model.

* Identifiable tags of the `v*` convention make it easier for SCM to identify available library versions 
  * Sort them newest to oldest, using semver sorting 
  * Identify the current release 
* Discrete release branches makes release management, breaking changes, and hotfixes more manageable 

### Feature Branches ( `feature/*` ) 

Use this convention for feature-specific branches if you're doing long-term development 

{% hint style="danger" %}
**NOT FULLY IMPLEMENTED** \
The idea will be that deployments from a feature branch will be distinct in one of two ways;

* Deploy to a different workspace 

* Add a suffic to the library name so that it loads in parallel, in your test workspaces 
  {% endhint %}

* Other branches can be used for experiments 

## Future

We'll look at; 

* Standardizing other tags

## Deploying a Release 

Prep integration; 

1. Merge any necessary code from feature branches into main, if you're deploying a new feature 
2. Update the library VERSION 

Testing; 

1. Run unit tests 
2. Deploy main to your test Webflow workspace and fully test your work  

Release; 

1. Create a new Release branch if you have a new major or minor version <br>

   ```
   git checkout -b release/0.1
   ```
2. PR your changes from main to the appropriate release branch&#x20;
3. Tag this commit <br>

   ```
   git tag v0.1.3
   ```
4. Push the Re

### Creating a new Release Branch&#x20;

From main&#x20;

{% hint style="warning" %}
Use major.minor only.&#x20;
{% endhint %}

e.g.

```
git checkout -b release/0.1)
```

\\