On 2020-12-30 11:50:10, Apollon Oikonomopoulos wrote: > Hi all, > > Now that we've officially released 3.0, it's time to look a bit at > stable release management. What I'd like to discuss in particular is the > possibility of switching from a forward-porting workflow for stable > updates to a back-porting one. > > Ganeti traditionally relied on a forward-porting, merging workflow for > the stable branches: a bugfix would always target the *earliest* stable > branch it should be applied on, and stable branches would subsequently > be merged upwards and finally into master¹. So, to fix a bug that was > introduced for instance in 2.15, we would commit the fix on stable-2.15, > and then successively merge stable-2.15 into stable-2.16, stable-2.16 > into stable-3.0 and stable-3.0 into master.
Minor correction: Ganeti originally used back-porting, then switched to forward-porting during the 2.1 release or so. It is not technically relevant, but since we're discussing history anyway… Yes, back-porting was very painful during the 1.2/2.0 era. Forward-porting was not chosen arbitrarily, but rather to solve a real problem (that resulted in many production bugs). [snip rest] > I think we could try a back-porting strategy for the 3.0 stable release > cycle, in the hope that it allows for faster development on master and > simpler PR workflows. If we end up not liking it, we can always revert > to the forward-porting strategy without a problem. What do you think? I think back-porting is more practical, but if we do it, we should ensure that the original commit ID is recorded (`git cherry-pick -x`), so that at least we have a weak trail of record. regards, iustin -- You received this message because you are subscribed to the Google Groups "ganeti-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to ganeti-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ganeti-devel/X/BYvDVyN/j/9aCa%40teal.hq.k1024.org.
