versioning artefatto - versioning del prodotto vs versioning semantico

Naviga le tue risposte
0

La seguente situazione:

  • un prodotto costituito da più componenti, ogni componente versione singola (tutti gli artefatti dello stesso componente con la stessa versione)
  • Gli OP stanno parlando della versione X del prodotto e del piano rilascia X.a, X.b che contiene funzionalità specifiche
  • a ogni sprint viene creata una nuova versione (potenzialmente installata su un ambiente demo)
  • le versioni sprint aumentano la versione della patch, ad es. 1.0.0, 1.0.1
  • la versione minore verrebbe aumentata una volta che avvieremo lo sviluppo alla prossima release pianificata dalle OP, ad es. X.a = 1.0 e X.b = 1.1

Abbiamo iniziato la discussione sull'introduzione del versioning semantico ( link ) per i componenti ma ci sono alcuni dubbi.

  • Alcuni lo trovano reso più complicato se lo sviluppatore deve decidere se la versione secondaria o patch deve essere aumentata e sollevato il punto che alcune correzioni di bug introducono nuove funzionalità (non chiedere)
  • Alcuni stanno rifiutando l'idea di aumentare la versione secondaria in quanto la versione pianificata dagli ordini di acquisto potrebbe non essere ancora raggiunta, anche se non è ancora completa.
  • Con l'ingegneria delle versioni corrente è possibile visualizzare facilmente quale ambiente è potenzialmente necessario aggiornare a seconda che la versione sia 1.0.xo 1.1.x
  • Rilasciando in base alla versione semantica dopo ogni sprint raggiungeremo versioni maggiori e minori che non piacciono anche perché alcuni clienti curiosi controllano le versioni

Quali pratiche si applicano ad altre aziende quando si parla di versioning in un ambiente di mischia? Rilasciate una versione dopo ogni sprint? Dove vedi i vantaggi dell'approccio scelto?

EDIT: Forse non era chiaro dalla mia descrizione, ma le versioni dei componenti non si allineano esattamente con le versioni del prodotto, l'unica correlazione tra i due è il momento in cui maggiore / minore sarà aumentato ad esempio :

  • prodotto 1.0
    • componente A 3.2
    • componente B 4.5
  • prodotto 1. 1
    • componente A 3. 3
    • componente B 4. 6
  • prodotto 2 .0
    • componente A 4 .x
    • componente B 5 .x

Sono d'accordo che la versione del prodotto non dovrebbe avere nulla a che fare con la versione tecnica - è un'etichetta. Ecco perché sto cercando di scoprire come gli altri hanno risolto questo e quali erano gli argomenti. ;)

    
posta Clauds 29.06.2017 - 11:00
fonte

1 risposta

4

Una soluzione semplice, non solo per i team agili, consiste nel separare la versione di progettazione dalla versione di marketing. Una ben nota istanza di questo è la versione di Microsoft per Windows NT:

  • la stessa prima versione era 3.1, non 1.0
  • versione di marketing Windows 2000 , versione di progettazione Windows NT 5.0 (MS ha deciso di interrompere lo sviluppo delle versioni basate su DOS e di conseguenza ha eliminato NT dal nome del prodotto, nonostante allo stesso tempo sia stato rilasciato Windows ME
  • versione di marketing Windows XP , versione di progettazione Windows NT 5.1
  • versione di marketing Windows XP Professional x64 , versione di progettazione Windows NT 5.2 (È interessante notare che la porta di AMD64 ha il proprio numero di versione, mentre Windows XP 64- Bit Edition , la porta su IA64, no)
  • versione di marketing Windows Vista , versione di progettazione Windows NT 6.0
  • versione di marketing Windows 7 , versione di progettazione Windows NT 6.1 (in realtà, la versione di progettazione era originariamente 7.0, ma Microsoft ha scoperto durante i test di compatibilità che un sacco di software era testando per major == 6 per capire se abilitare le funzionalità post-XP, e piuttosto che rompere tutte quelle app, Microsoft ha deciso di ripristinare la versione principale a 6. Durante il keynote, hanno scherzato sul fatto che Windows 8 avrebbe avuto la versione 6.1.1, e così via, per lo stesso motivo.)
  • versione di marketing Windows 8 , versione di progettazione Windows NT 6.2
  • versione di marketing Windows 8.1 , versione di progettazione Windows NT 6.3
  • versione di marketing Windows 10 , versione di progettazione Windows NT 10.0 (MS ha riallineato le versioni di marketing e ingegneria con Windows 10, tuttavia a causa del nuovo modello a rotazione, è immaginabile che la versione di ingegneria possa cambiare ma la versione di marketing rimane la stessa)

[Si noti che Microsoft ha anche numeri di rilascio e numeri di build che aumentano monotonicamente, nessuno dei quali compare nelle versioni di marketing.]

Quindi segui SemVer per le tue versioni di ingegneria (che, in un progetto agile porterà probabilmente a numeri di versione elevati), e il reparto marketing è libero di scegliere il loro schema di versioning come vogliono. Puoi pensare a una versione di marketing come una breve etichetta leggibile da un umano per un insieme di funzionalità che, per così dire, sono formattate come un numero di versione.

    
risposta data 29.06.2017 - 11:26
fonte

Leggi altre domande sui tag

In che modo il servizio di prenotazione taxi seleziona le coordinate del conducente più vicine? Relazioni e vincoli del database gestiti nel software applicativo [chiuso]