Versione software, è possibile saltare i numeri di versione?

-3

Quindi abbiamo un codice base che gradle si basa su 3 diversi target per 3 diversi clienti che sono completamente separati da una prospettiva di business. Per semplificare il nostro flusso di lavoro di rilascio, abbiamo scelto di mantenere lo stesso controllo di versione per tutti i target, in quanto meno del 5% delle modifiche sono specifiche del client e preferiremmo tenere traccia di una versione rispetto a 3.

Diciamo che apportiamo una modifica al codice base che riguarda solo il bersaglio A e lo ha rilasciato per il bersaglio A.

Abbiamo due opzioni per B e C:

  1. Salta semplicemente la versione, non parlarne nelle note di rilascio, non esiste.
    • Non sembra molto bello ...
    • Mi chiedo se i clienti potrebbero percepire questo aspetto negativo
  2. Versione di rilascio per tutti e tre i target:
    • Le note di rilascio avranno qualcosa di molto generico (che è anche una bugia): "correzioni e miglioramenti"
  3. Prova a raggruppare le modifiche in modo che nelle pubblicazioni sia sempre presente qualcosa di cui parlare
    • Ad esempio, se apporto una modifica specifica per A, impacchetta una funzione o una correzione di bug non specifica per il target in modo che la versione sia un aggiornamento legittimo per tutti i target.
  4. Dividi il versioning in 3 e tiene traccia di quale versione in A, B e C corrispondono l'una all'altra
    • Ultimo resort

Qualche suggerimento?

Aggiornamento: Per motivi di lavoro, non possiamo parlare di un cliente con gli altri clienti perché, dal punto di vista del business, i prodotti sono in realtà diversi.

    
posta Jbezos 27.09.2017 - 09:38
fonte

3 risposte

0

Va bene saltare i numeri di versione.

  • Java è passato dalla versione 1.4 direttamente a 5.
  • Angular è passato dalla versione 2 direttamente a 4.

Non tornare mai indietro o fare versioni di versioni confuse come Microsoft ha fatto con Windows (3.1, 95, 98, 2000, ME, XP, Vista, 7, 8, 10)

Per evitare il tuo problema attuale:

  • Non hai mai codice client specifico. Prendi invece un approccio alla funzionalità. Se il cliente A ha bisogno di una caratteristica speciale X e il client B ha bisogno della caratteristica Y, puoi citare correzioni di bug per presentare X senza dover divulgare le informazioni sul client A al client B.
  • Se non puoi evitare il codice specifico del client, prova a esternarlo in una libreria esterna (DLL / jar). Se il codice specifico del cliente richiede correzioni o miglioramenti, puoi aggiornare la tua biblioteca senza il potenziale rischio di influenzare altri client.

Non mentire ai tuoi clienti. Se hanno mai riscontrato un problema per il codice che era destinato a un altro cliente, potrebbero scoprire che hai mentito a loro e questo può avere conseguenze (anche legali) per il tuo business.

    
risposta data 27.09.2017 - 10:28
fonte
4

Perché non essere onesti a riguardo? Basta mettere un disclaimer generale da qualche parte:

Some release contain only client-specific fixes, so not every release is made to every client.

    
risposta data 27.09.2017 - 09:58
fonte
2

Di solito i clienti non si preoccupano molto dei numeri di rilascio accettati per ottenere l'ultimo, ma tu sì. Pertanto è ok saltare i numeri di rilascio per i clienti che non sono interessati dal rilascio "saltato".

Per lo stesso motivo potresti semplicemente cambiare il tuo numero di rilascio sheme da numeri consecutivi a month/year come abbiamo per alcune distro di Linux. Ciò eviterebbe discussioni con il marketing ...

    
risposta data 27.09.2017 - 10:05
fonte

Leggi altre domande sui tag