krzywon
commented
1 month ago Here is a simplified version of what Paul has with a top-to-bottom view of the history instead of left-to-right view.
--- title: SasView development and release process --- %%{init: { 'logLevel': 'debug', 'theme': 'default' , 'themeVariables': { 'commitLabelFontSize': '30px' } } }%% gitGraph TB: commit id:"start" branch Patch branch Features branch Major_version_change checkout Patch branch bugfixA commit id:"bugfix 1" checkout Features branch Feature1 order: 11 commit id:"New Feature 1" checkout Features merge Feature1 checkout Patch merge bugfixA checkout main merge Patch id:"release 1.0.1" checkout Features merge main checkout Major_version_change merge main checkout Major_version_change branch Breaking1 commit id:"Breaking Change 1" checkout Major_version_change merge Breaking1 checkout Features branch FeatureRelease1 commit id:"fix bug again" commit id:"oopsy" commit id:"oops again" checkout Features merge FeatureRelease1 checkout main merge Features id:"release 1.1.0" checkout Patch merge main checkout Features merge main checkout Major_version_change merge main checkout Patch branch FeatureRelease2 commit id:"fix bug" checkout main merge Patch id:"release 1.1.1" checkout FeatureRelease2 merge main checkout main merge FeatureRelease2 id:"release 1.2.0" checkout Patch merge main checkout Features merge main checkout Major_version_change merge main branch MajorRelease1 commit id:"some changes" commit id:"some more fixes" checkout main merge MajorRelease1 id:"release 2.0.0"
wpotrzebowski
lucas-wilkins
rozyczko
A hierarchical workflow to enable a professional release cycle in an amateur development environment: Proposal for a new SasView release process.
Problem statement
CURRENT: The SasView release cycle is slow, irregular and almost always buggy on release. There have been lots of discussions about "release early release often." While this sounds reasonable in the abstract, it never ends up being practical when the rubber hits the road.
DESIRED: A method that allows for rapid bug fix releases and a regular cadence of feature releases which are relatively robust and bug free that accounts for the way the project is actually resourced rather than how it wishes it were resourced.
CONSTRAINTS: The way the project is resourced is quite lean, opportunistic and, most importantly, very sporadic. This is not likely to change significantly in the foreseeable future.
The number of volunteer developers for SasView remains small with the appropriate expertise often dispersed among several different people, most or all of whom can only work on SasView issues when their regular jobs allow. This can sometimes mean weeks or even a month hiatus of a critical person. This is a very different environment than most open source projects of note (python, numpy, scipy ... even Mantid for that matter) which have a cadre of people committed to the project (or with at least part of their week dedicated to the project). Thus what works best in those environments may not be appropriate in this case.
Analysis
Looking at "best practices" in version control workflows for software projects suggests that a single, continuously releasable main branch, with possibly a very long running parallel "next major release" branch ( e.g. developing version 4 while still releasing new features in 3), provides the minimum wasted overhead effort. As more permanent parallel branches are added (patch branch, feature branch etc.) the more tedious the maintenance of all those branches simultaneously becomes.
The current SasView workflow is essentially the single permanent branch approach but has proven to create very long release cycles with a lack of agility for small bug fixes etc. Moreover, code freezes often stymie the ability of the very few contributors who have time to work on major projects. However, this is not that surprising given that the requirements for this "best practice" approach seem to be:
The SasView project does not meet any of these, nor will it realistically be able to anytime in the foreseeable future. In fact it would be difficult to claim that
mainis "continuously releasable."Furthermore, The complexity of the overhead will be high in large projects because commits are coming into the various permanent branches at a steady clip making it hard to keep the up with synching the permanent branches, with the attendant conflict resolutions, which themselves could introduce new bugs. Again, this is not the case with the SasView project where the pace of commits is much slower.
Proposal
Here we propose a different optimization choice by going with a more hierarchical approach that increases the branch maintenance overhead in favor of simplifying the release process by minimizing the interference between changes of different levels of complexity (there is no free lunch). The extra overhead to regularly merge branches back up the hierarchy tree, resolving possible merge conflicts, and the extra maintenance issues, particularly for the refactoring branch should payoff by allowing for rapid bug fix releases and for a simple feature release cycle on a regular schedule without slowing down major refactoring/breaking change efforts.
The model consists of 4 permanent locked branches. We could do it with 3 but conceptually 4 seems cleaner to me:
To avoid confusion in the process, if a "simpler branch" is ready for release at the same time as a higher level branch (more complex) then the simpler branch should be released first. The resulting main should then be merged back into all branches, including the other release branches being worked.
This should allow for the following release cadence almost independently of resources or timing thereof:
NOTE: information on mermaid commands can be found in the mermaid documentation at: https://mermaid.js.org/syntax/gitgraph.html)