@estilo/estilo-design-system

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.

1. a versão MAJOR é incrementada para mudanças incompatíveis (breaking changes)
2. a versão MINOR é incrementada para adicionar funcionalidades de forma compatível com as versões anteriores.
3. 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.