1 Reply Latest reply on Apr 24, 2012 11:35 AM by lfryc

    Micro-release strategy issues

    lfryc

      We were discussing branching model for 4.2.1 release on the meeting 2012-04-17.

       

      The problem is release/4.2.1.Final branch was opened to handle long-term work on that branch.

       

      Along the way, we have setup continuous integration for this branch.

       

      Finally, we have changed versions on this branch from 4.2.1-SNAPSHOT to 4.2.1.Final.

       

      ----

       

      We have implemented this model since we identified the originally designed workflow won't work since it would require a lot of cherry-picking (develop on branch and cherry-pick to release-minor branch).

       

      ----

       

      But it brought some issues:

       

      • when switched version, Jenkins started to release bits into staging repository
        • that's not problem, since these staging repos were unmaintained, they were cleared automatically
      • the branch was integrated into develop after finishing release/4.2.1.Final branch
        • having lot of changes in release/4.2.1.Final outside of develop
      • one commit was missed when releasing, which was found when finishing branch (after release)
        • which was caused by abusing release branch to actual development
        • 1. Re: Micro-release strategy issues
          lfryc

          As we have discussed, the origianl Git Flow didn't run into this problem, since it was designed for short-running hotfix releases instead of long-running development on branch divergred from tag.

           

          ----

           

          To fix this, I would suggest following strategy in next minor release:

           

          • opening
            • open the develop/4.2.1.Final branch from 4.2.1.CR1 tag
            • switch the version to 4.2.1.Final-SNAPSHOT (to distinguish bits in continuous integration)
          • development
            • sprint on develop/4.2.1.Final branch
          • release
            • open the release/4.2.1.Final branch
            • switch version to 4.2.1.Final
            • integrate develop/4.2.1.Final to develop
            • continue with release as usual
          • continue with develop (having changes from develop/4.2.1.Final)
            • could be even parallel to release