Replies: 2 comments
-
|
I suggest to stick with what is the standard with different version control systems: develop on trunk/master/main/dev at any time with features and if you feel a reason for a patch release branch using the last release tag as source with naming the branch like the release tag + ".x" or similar, then do any patches there and merge them to trunk/master/main/dev if still appropriate (if not fixed there already in which case you either cherry-pick for merging the feature or, if it is too different rewrite the patch for the specific release branch). [and in general I think we should get a release out; release "often" is not bad, especially if it is - in this case mostly about re-checking the ChangeLog and set an appropriate tag] |
Beta Was this translation helpful? Give feedback.
-
|
That would be fine with me. That does require a second development branch (e.g., release/0.26) be created. I don't have any problem with that and would prefer this to at least the current approach. We have a moving target with potential patches for the previously released version. The current list is in the milestones for each release, but that doesn't mean the 0.26.1 milestone might have additional issues added (or removed) in the future before it gets released, or that additional patch releases might occur prior to the next feature release. Merging of the CHANGELOG between the release branch and the development branch might require manual intervention as both branches would be updating it at the top of the file, thus it is likely to need to be manually merged. Within that release branch, I could see tags created for the initial (e.g., 0.26.0) release and patch releases (e.g., 0.26.1). It might also make sense for all of the version updates (i.e., package.json) to take place on the release branch and leave the one in the development branch a generic version, or at least an alpha/beta version targeting the next major release. |
Beta Was this translation helpful? Give feedback.
-
I've been debating how to handle working on next release features when we potentially need to generate intermediate patch releases for the previous release. For example, it's difficult with the current single development branch to work on both 0.27 features as well as 0.26.x patches.
If these are mixed together than users have to wait for 0.27 to be released to get patches related to the 0.26 release (since new features technically shouldn't be released in a patch version), or be forced to release 0.27 earlier than desired so that the patches are available to users. Releasing earlier than desired can affect the milestones which have been planned for that release and will likely cause re-planning to push those to a future release.
The other option (and which I have been doing) is to not work on or put anything destined for 0.27 into the repository. Thus, 0.26.1 patches can safely be applied into the main development branch and the patch release can be cut at any time. The problem with this is that no work happens on new features. At some point you have to start introducing new features or there won't be a new release other than bug fixes.
I wonder if it would be helpful to utilize a process, such as git-flow (or even some other solution) that would allow work on new features while still retaining the ability to create and release patch versions of the previously released version. The process would likely involve using multiple branches to perform feature work destined for the next release and branch(es) to perform hotfixes/patches and merging between them at the appropriate points in time.
Looking for some input or ideas on how we might address this.
Beta Was this translation helpful? Give feedback.
All reactions