Github Protocol
Last updated
Sygnal Component Marketplace ( SCM ) uses Github for the storage and deployment of Code Components to subscribing Webflow Workspaces.
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/* ) 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
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.
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/* ) Use this convention for feature-specific branches if you're doing long-term development
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
Other branches can be used for experiments
We'll look at;
Standardizing other tags
Prep integration;
Merge any necessary code from feature branches into main, if you're deploying a new feature
Update the library VERSION
Testing;
Run unit tests
Deploy main to your test Webflow workspace and fully test your work
Release;
Create a new Release branch if you have a new major or minor version
PR your changes from main to the appropriate release branch
Tag this commit
Push the Re
From main
Use major.minor only.
e.g.
\
Last updated
git checkout -b release/0.1git tag v0.1.3git checkout -b release/0.1)