Having a defined Git workflow is crucial for efficient and organized software development. As a developer working on Julia projects and other open-source projects, not having a defined workflow has been frustrating and has impacted my development speed and performance. Working with others has also been challenging due to the lack of a clear and shared workflow.
Realizing the need for a defined workflow, I decided to take the time to define one. After researching various workflows, such as Gitflow workflow and GitHub flow workflow, I concluded that combining the best features of both would be the most effective approach. This led me to create a workflow known as Continuous-Release Workflow.
The Continuous-Release Workflow focuses on continuous delivery and rapid releases. It involves creating and maintaining feature branches, conducting code reviews, andmerging changes into a development branch for testing. Once the changes pass the tests, they are merged into the master branch and released to the users. This workflow allows for continuous integration and deployment, leading to faster feedback loops and improved collaboration.
However, this workflow has not been tested over many projects yet, and feedback from the development community is essential to refine and improve it. Therefore, I invite others who are facing similar problems with a lack of a defined workflow to contribute to and advance the Continuous-Release Workflow. I would also appreciate the input of experts in this area to improve the workflow’s readme.md and overall implementation.
In conclusion, having a defined Git workflow is crucial for efficient software development, and the Continuous-Release Workflow can be an effective approach. I encourage other developers to contribute to this project and refine the workflow to improve collaboration and accelerate software development.
You may be interested in ColPrac (The Contributor’s Guide on Collaborative Practices for Community Packages) which is a set of practices widely (but not universally) used in the Julia community.
While neither is as formalized as yours they do lead to what i think is the most common workflow.
Which is a bit simpler than what you put forward.
PRs are made to main, the PR increments the version number appropriately see ColPrac for details on that, but basically follow SemVer. (Sometimes the PR doesn’t but instead the maintainer increments it after merging. Either works.)
A release is immediately tagged off main after merging (unless the version has been set to X.Y.0-DEV)
If the version is currently set to X.Y.0-DEV then batch up changes preparing for a release. (Mostly relevent only for if breaking, or a major project)
If there is a need to backport something, then a branch is created (if it doesn’t already exist) at the point of the previous release with the right minor version number called release-X.Y and changes are cherrypicked on to it from main, and a release is tagged off that branch. You can backport to any past version that seems needful.
I personally have found that is sufficient even for large code-bases and large distributed multi-teams. Its also more or less what is done for Julia itself, except for julia itself always does point 3 setting to -DEV and batching up changes.
The only thing confusing to me about your system is that you have a release-vX.Y.Z rather than a ``release-vX.Y. If you don't let the patch (Z`) version number change you do you do releases?
The only thing confusing to me about your system is that you have a release-vX.Y.Z rather than a ``release-vX.Y. If you don't let the patch ( Z`) version number change you do you do releases?
I do not clearly understand what you mean by that.
The julia community has nearly everyhting I think I can want and with many packages such as PkgTemplates , it can be automated. However I don’t think there is a define git workflow that is predominantly used in the community, so contributing to packages would be straightforward, which is one main reason I took the time to develop this.
How common is the problem that you are trying to solve?
I would guess for 90% of julia packages a workflow like this is less efficient than what they currently do - just merging passing (and reviewed if reviewers exist) PRs to main and bumping versions as they go. I rarely see real life situations where that is not actually fine.
Once you hit a few hundred stars/dependencies and a bunch of contributors pushing at the same time, it may start to be necessary to have some controls in place, and your workflow may be useful in that context.
But the real bottlenecks are usually social - like not enough time to do the needed reviews, and PRs rotting because no one can get to them.