2014-11-22 14 views
5

Sto cercando una definizione formale dei formati dei numeri di versione per i file .NET core project.json.project.json versioning format

versione
studio visivo crea un numero di versione di default di "1.0.0- *". Mi piacerebbe che questo significasse che * si aggiorna su build successive (non lo fa). Il numero di versione della build è 1.0.0. Cosa significa * e quali sono le possibilità legali?

dipendenze
Mi aspettavo la dipendenza numerazione di seguire la NuGet versioning rules dato che KPM è fondamentalmente un front-end NuGet, ma non sembra supportare la numerazione staffa (ad esempio "[1,2)") - Ricevo "non una stringa di versione valida" quando provo qualcosa di diverso da un formato vuoto o xx- *.

Al di fuori della sorgente, qualcuno ha un collegamento a una definizione formale?

+0

Vedere questo https://github.com/aspnet/KRuntime/issues/442 e anche i commenti nella relativa richiesta di pull. – AndersNS

+0

Facciamo questo con la nostra build e probabilmente lo dovremmo inserire in KPM. I nostri script di compilazione impostano la variabile di ambiente K_BUILD_VERSION su un timestamp. Questo incrementa automaticamente la versione ogni volta che creiamo una copia locale. – davidfowl

risposta

0

Non sono sicuro di cosa non funzioni guardando nella sorgente per una definizione. Penso che sia il posto più preciso da cercare, specialmente ora che vNext è ospitato su GitHub.

Osservando l'eccezione descritta, siamo puntati su SemanticVersion.cs.

In the method TryParseInternal, it's fairly obvious why you're running into issues when attempting to declare min/max versions that way. Semplicemente non esiste una gestione per [,] o (,) integrata in tale metodo.

Se guardiamo nel regolare specifica versione NuGet, it's obvious that TryParseVersionSpec does have this handling built in.

Per quanto riguarda la documentazione specificando formati accettabili, probabilmente dovrete aspettare fino a quando è fuori dello stato CTP. Se ritieni che si tratti di un problema, devi document it in GitHub. I contributori sono molto sensibili a questi tipi di problemi. Personalmente non sono sicuro se sia necessario impostare una versione massima di una dipendenza quando viene distribuita con la build.

+1

Immagino di sentire che il codice definisce come sono attualmente implementate le cose, non necessariamente come dovrebbero funzionare o come dovrebbero essere utilizzati. Oltre a ciò, il livello di difficoltà richiesto per utilizzare il codice come documentazione è piuttosto alto. Immagina di utilizzare il sorgente del compilatore .net per la documentazione invece di MSDN –

+0

@MattFrost: Il mio punto è che probabilmente non troverai documentazione aggiornata a questo punto, dato che la specifica è in fase di sviluppo/perfezionamento come è codificata. Sarei estremamente stanco di qualsiasi documentazione che trovi a questo punto. – grovesNL