Politica di cherry-pick extra-version stabile

Pavilion sta valutando di supportare ufficialmente la branch stable per alcuni dei nostri plugin, a partire dal plugin Custom Wizard.

Da tempo diverse persone hanno chiesto un’alternativa al supporto tests-passed per alcuni dei nostri plugin (in particolare per il plugin Custom Wizard), e la combinazione di una massa critica di richieste e del fatto che il plugin si trovi ora in uno stato regolarizzato (copertura dei test, CI, versionamento semantico, ecc.) ci porta a prendere in considerazione questa opzione.

Alcuni amministratori di forum, che cercano qualcosa di più stabile del supporto tests-passed nel plugin, fissano i loro forum a versioni specifiche, una alla volta. Una delle preoccupazioni espresse da questo gruppo di amministratori riguardo all’adozione di stable è che commit aggiuntivi vengono selezionati (cherry-picked) sulla branch stable al di fuori delle release specifiche.

Se questi amministratori di forum adottassero anch’essi stable (in linea con il plugin), starebbero adottando questi commit aggiuntivi al di fuori delle versioni regolari. La politica o l’approccio relativo al cherry-pick influenzerebbe anche il modo in cui manteniamo la branch stable per il/i plugin.

Esiste una politica su quali tipi di commit vengono selezionati? Ho avuto l’impressione che i commit selezionati su stable al di fuori delle versioni specifiche siano (ora) limitati alle patch di sicurezza e alle correzioni di bug, mentre in passato l’approccio era talvolta più liberale.

Esiste attualmente una politica su ciò che viene selezionato su stable al di fuori delle versioni (“extra-version cherries”)?

Solo gli aggiornamenti di sicurezza e le correzioni di bug vengono retroportati nella versione stabile. Fanno eccezione le prime settimane successive al rilascio di una nuova versione di Discourse, durante le quali verranno retroportati piccoli fix di bug per creare la prima release di aggiornamento di quella versione.

In sostanza: