JSPM – @estilo/estilo-design-system@0.0.1

Package Exports

This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (@estilo/estilo-design-system) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.

Readme

Semantic Versioning - MAJOR, MINOR e PATCH

Link para a documentação

SemVer é um padrão para atribuir números de versão a projetos de software, com o objetivo de facilitar o gerenciamento de dependências e fornecer informações claras sobre as mudanças introduzidas em cada versão.

a versão MAJOR é incrementada para mudanças incompatíveis (breaking changes)
a versão MINOR é incrementada para adicionar funcionalidades de forma compatível com as versões anteriores.
a versão PATCH é incrementada para correções de bugs compatíveis com versões anteriores

Versões SemVer seguem o formato X.Y.Z, onde X é a versão principal, Y é a versão secundária e Z é a versão de correção.

Fluxo de trabalho

A ideia é a mesma e segue como o modelo gitflow funciona.

A partir da branch crie uma outra branch com o prefixo e dado o cenário que se encontra no momento

# É uma feature?
git checkout develop && git pull
git checkout -b feature/CE-XXX-YYYY

# É um bugfix?
git checkout homolog && git pull
git checkout -b bugfix/CE-XXX-YYYY

# É um hotfix?
git checkout master && git pull
git checkout -b hotfix/CE-XXX-YYYY

Workflow

git checkout develop && git pull
git checkout -b feature/CE-999-new-input

Entre no seu package.json e suba uma versão com base nos critérios da semantica de versionamento (MAJOR, MINOR e PATCH)

{
    "name": "@estilo/estilo-design-system",
    "version": "0.1.0",
    // era 0.1.0 ? suba uma versão 👇
    "version": "0.2.0",
}

Finalizado a implementação ?

Commit
Abre PR
Aponta para develop

Aprovado ?

Merge com a develop através do BitBucket

# troca pra homolog
git checkout homolog && git pull

# a versão da release precisa ser exatamente a mesma do package.json
# que foi alterado a cima
git checkout -b release-candidate/v0.2.0

Feito ?

Abre a PR apontando para homolog

Aprovado ?

Merge com homolog através do BitBucket

git checkout release-candidate/v0.2.0

# a partir da release-candidate, abra a release
git checkout -b release/v0.2.0

Feito ?

Abre a PR apontando para master.
Assim que aprovado o código e o codigo cair na master, a pipeline irá rodar e a versão a ser subida para o NPM sera a mesma do package.json.