Come denominare rami diversi con funzionalità identiche in Versioning semantico

Should I release these packages with different version names using Semantic Versioning? In my opinion, yes, but what about the naming of these different versions?

Non dovresti cambiare la versione a meno che il tuo codice non cambi. Tuttavia, il tuo attuale approccio di accodamento della versione della libreria funziona bene secondo le regole del Semantic Versioning, ma devi usare un segno + per aggiungere la dipendenza della libreria:

• 1.0.0
• 1.0.0 + JSON-c-0.10

Per il rilascio, e assumendo che il nome del pacchetto sia purestjson , questo dà:

• purestjson-1.0.0
• purestjson-1.0.0 + JSON-c-0.10

Logica: Versioning semantico afferma nella regola 10:

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

Ci sono due casi:

• Se sei sicuro di non rilasciare mai una versione backward incompatibile della vecchia libreria delle dipendenze, e se la visibilità implicita ridotta della versione delle dipendenze precedente non ti dà fastidio = > utilizzare 1.x per il precedente, 2.x per il più recente;
• Tutti gli altri casi: usa un nome di pacchetto diverso, non disambigui per versione;

Tuttavia, se mi trovassi di fronte a un problema del genere, reimposero il codice a un modello "basato sul fornitore", in cui il codice client chiama in un fornitore astratto e fornirei "implementazioni del provider" sia per il vecchio e le nuove versioni delle dipendenze. Questo è il modello che viene utilizzato da JDBC o ADO.NET ad esempio per supportare qualsiasi tipo di database SQL. Certo, è più lavoro, ma se hai entrambi i clienti che hanno bisogno della dipendenza più vecchia e di altri clienti che hanno bisogno della nuova dipendenza, questo è, secondo me, il modo più razionale di gestirli e supportarli.

I'm not a C developer, so please excuse the terminology errors.

Versione semantica e rami di codice (incluso codice di terze parti)

Da una prospettiva di versioning semantico penso che ci siano alcuni modi in cui è possibile avvicinarsi alla denominazione della versione e dipende da come si vorrebbe avvicinarlo da un repository GIT per un progetto C.

1. Nel tuo caso, l'API ha raggiunto la versione 1.0.0 e sembra che tu abbia creato un'opzione di compilazione diversa per consentire agli utenti di utilizzare le precedenti edizioni di alcuni codici della tua libreria. Il tuo in un punto, in cui offre una regressione a una vecchia versione o codice. Lo vedo come un piccolo cambiamento come da regola 7:

   Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

2. regola 10 , implica che dovresti includere "+ Alpha", "+ Beta", "+ RC" o "+ RTM 'o [BLANK] piuttosto che' json-c-0.10 'che hai scelto nel tuo Git Repo. Inoltre, se si dovesse continuare ad usare l'approccio 'json-c-0.10' e si hanno più librerie all'interno dell'API, si potrebbe ottenere un nome di file molto lungo. Ho anche visto "+ Dev", "+ Nightly", "+ Stable" incluso nei nomi per aiutare gli sviluppatori a testare il codice.

3. Dai un'occhiata all'utilizzo del MakeFile che configura l'output per generare varie cartelle che rappresentano il modo in cui il file API viene compilato con varie opzioni. Si noti che il nome del file di output è lo stesso, appena memorizzato in una cartella diversa. Ad esempio:

   /Output/Linux/Nightly/purestjson-1.1.0.exe

   /Output/Mac/Nightly/purestjson-1.1.0.exe

   /Output/Windows7/Nightly/purestjson-1.1.0.exe

   / Output / * / Stable / purestjson-1.1.0.exe

   / Output / * / Vecchio / purestjson-1.1.0.exe

   / Output / * / Personalizzato / purestjson-1.1.0.exe

   Esempi di definizioni di cartelle

   Puoi quindi fornire alla comunità API quale MakeFile Target per le combinazioni di codice di terze parti personalizzate.

   Nightly - Potrebbe includere tutto il codice Git spinto da tutte le librerie di terze parti.

   Stabile: codice dalle versioni correnti della libreria di terze parti.

   Vecchio - Codice delle versioni precedenti delle librerie di terze parti.

   Personalizzato: consente all'utente di selezionare e scegliere l'edizione di una libreria di terze parti che desidera utilizzare.

4. Scopri come utilizzare Git con rami, funzionalità, rilasci e correzioni di errori. C'è un'estensione git che potresti trovare utile chiamata GitFlow e un approccio popolare di Vincent Driessen discusso nel suo ''Ricevuto modello GIT Branching model '. Atlassian fornisce una GUI per Windows / Mac che include GitFlow chiamato SourceTree .

5. Una cosa che potresti voler pensare è usare un server di integrazione continua per compilare il software e includere "+ IncrementalBuildNumber" o "+ YYYYMMDD" per aiutare con il test dell'unità.

Rimozione delle modifiche alle API

Questo è un problema comune per gli sviluppatori API. Ho visto alcune soluzioni al problema.

1. Falla interrompere rimuovendo i vecchi metodi. Non molto adatto alla comunità
2. Crea avvisi del compilatore per metodi API obsoleti. In .NET World è possibile includere informazioni per lo sviluppatore del software che spiegano come migrare i vecchi metodi a nuovi metodi o collegamenti a pagine Web che lo spiegano. Ciò aiuterà la tua comunità API a capire cosa cambiare da / a.
3. Se possibile, mantieni i vecchi metodi e usa le nuove chiamate API all'interno di quei metodi obsoleti, mentre avvisa lo sviluppatore tramite gli avvertimenti del compilatore che il codice verrà rimosso in un momento successivo (raccomandabile alla prossima versione principale). Ciò consente agli sviluppatori un ciclo di rilascio della versione "Major" per ottenere il codice in ordine. In sostanza, dare la possibilità alla tua API Community di rimuovere le chiamate API ridondanti senza interromperle si costruisce immediatamente. Soluzione ottimale che consente avvisi senza errori di compilazione ma a scapito del codice gonfiato.

Nella mia azienda utilizziamo la codifica Git per quel link

Questo comando elenca i tag in ordine alfabetico; l'ordine in cui appaiono non ha alcuna importanza.

You can also search for tags with a particular pattern. The Git source repo, for instance, contains more than 240 tags. If you’re only interested in looking at the 1.4.2 series, you can run this:

$ git tag -l 'v1.4.2.*'
v1.4.2.1
v1.4.2.2
v1.4.2.3
v1.4.2.4