Quali numeri di versione devo assegnare alle build su rami diversi come parte dell'integrazione continua per i progetti basati su NET Core?

Panoramica

Sto sviluppando un certo numero di applicazioni .NET Core e ho soddisfatto i miei attuali impegni di sprint in anticipo. Finché non inizia il mio prossimo sprint, sto usando il gioco per cercare di creare una pipeline CI per i miei progetti (questo non è stato assolutamente necessario visto che sono l'unico a lavorare su questi progetti, ma sarebbe utile automatizzare alcune delle cose che sto facendo manualmente manualmente.

Tuttavia, sono confuso sullo schema di numerazione delle versioni che dovrei adottare per supportarlo.

Ambiente

Nel caso in cui siano utili informazioni, sto tentando di configurare questo flusso di lavoro utilizzando i seguenti strumenti:

• Visual Studio per lo sviluppo del codice
• BitBucket da utilizzare come repository remoto
• Pipeline BitBucket da utilizzare per le build CI
• MyGet da utilizzare come feed del pacchetto e la posizione in cui trasferire i pacchetti durante le build

Dettagli

Tutte le impostazioni tecniche per questo sono andate abbastanza bene fino ad ora, ma sono perplesso nel cercare di capire quali numeri di versione dovrei assegnare alle build su rami diversi pur rimanendo conforme a versioning semantico e un flusso di lavoro stile GitFlow .

Diciamo che la mia precedente versione di alcuni X è 1.1.0. Se applico alcune modifiche su develop e lo pubblico nel mio repository (attivando una build), quale versione deve essere assegnata al pacchetto NuGet prodotto da quel codice?

Citando la raccomandazione di nvie qui :

It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier. Up until that moment, the develop branch reflected changes for the “next release”, but it is unclear whether that “next release” will eventually become 0.3 or 1.0, until the release branch is started. That decision is made on the start of the release branch and is carried out by the project’s rules on version number bumping.

Questo ha senso per me e suggerirei che - fino a quando non creerò un ramo di rilascio - dovrei attenermi alla numerazione delle versioni come ad es. %codice%. Tuttavia, negli schemi di controllo delle versioni semantiche una versione come questa viene considerata come una versione che porta fino a v1.1.0, cioè una versione precedente, che non è ciò che voglio.

Per complicare ulteriormente le cose, la CLI dotnet ti permette di assegnare la suffisso (ad es. durante una compilazione di elementi di configurazione), ma non altre parti della versione (maggiore, minore o numero di patch) - queste sono determinati rigorosamente dal file 1.1.0-unstable0023 corrispondente al progetto che si sta costruendo.

Per quello che vale, ecco come appare il mio project.json per il mio primo progetto adattato finora:

image: microsoft/dotnet:onbuild

pipelines:
  branches:
    develop:
      - step:
          script:
            -BUILD_CONFIGURATION=Debug

            # Generate build number
            # Note: may adapt this to use GitVersion.exe instead 
            - BUILD_NUMBER='git log --oneline | wc -l'
            - echo "Build number':' ${BUILD_NUMBER} (will be appended to the generated NuGet package version)"

            # Install NuGet
            - apt-get update && apt-get install -y nuget

            # Add credentials
            - nuget setapikey $MYGET_API_KEY -source https://www.myget.org/F/company/api/v3/index.json -configFile NuGet.Config
            - nuget sources update -name "Company MyGet Feed" -source https://www.myget.org/F/company/api/v3/index.json -user $MYGET_USER -pass $MYGET_PASS -StorePasswordInClearText -configFile NuGet.Config

            # Restore and test projects
            - dotnet restore
            - dotnet test test/<<Company>>.<<Product>>Web.BaseTypes.Tests
            - dotnet test test/<<Company>>.<<Product>>Web.DeviceComponents.Tests
            - dotnet test test/<<Company>>.<<Product>>Web.Utility.Tests

            # Pack projects
            - dotnet pack --configuration $BUILD_CONFIGURATION --version-suffix=build$BUILD_NUMBER project.json src/<<Company>>.<<Product>>Web.BaseTypes
            - dotnet pack --configuration $BUILD_CONFIGURATION --version-suffix=build$BUILD_NUMBER project.json src/<<Company>>.<<Product>>Web.DeviceComponents
            - dotnet pack --configuration $BUILD_CONFIGURATION --version-suffix=build$BUILD_NUMBER project.json src/<<Company>>.<<Product>>Web.Utility
            - dotnet pack --configuration $BUILD_CONFIGURATION --version-suffix=build$BUILD_NUMBER project.json src/<<Company>>.<<Product>>Web.Utility.JsonPathGrammar

            # Push generated packages
            # TODO

Strategia di versione corrente

Al momento, assegno i numeri di versione seguendo questo formato per le versioni di rilascio:

<major>.<minor>.<patch>

Eseguo il bump del numero di versione non appena avvii un ramo di rilascio, quindi tutte le build di pre-release da un ramo di release verranno generate semplicemente aggiungendo un suffisso bitbucket-pipelines.yml :

<major>.<minor>.<patch>-beta0000, <major>.<minor>.<patch>-beta0001, ...

Se devo produrre una versione preliminare e non ho ancora avviato un ramo di rilascio, eseguirò manualmente il bump dei numeri di versione nei file -betaxxxx pertinenti e produrrò build come questo:

<major>.<minor>.<patch>-unstablexxxx

Dove project.json è il numero completo di commit su xxxx dalla versione precedente.

Se qualcuno ha suggerimenti su un buon schema di numerazione delle versioni che funzioni per i progetti .NET Core adattati per un flusso di lavoro CI / CD, lo apprezzerei molto.