On 12/25/19 8:41 AM, Tom Eastep wrote: > On 12/25/19 7:00 AM, Roberto C. Sánchez wrote: > >> I favor including the documentation changes in the same MR as the code >> changes. I don't have a strong feeling on if the documentation changes >> should be in the same commit as the code changes or if code and >> documentation are changed in separate commits that are in the same MR. >> Though, the larger the code change, the more likely it makes sense to >> separate the documentation change into a different commit. Regardless, >> they should be in very near proximity to each other. >> > > They must be separate commits because they are in different repositories > (/code and /release). I believe that means that they will also be in > separate MRs. >
I should probably expand on why there are separate repositories. It is desirable to be able to perform merges between branches (as opposed to cherry-picking individual commits). The way that I have always worked is that I develop each new major or minor version in the master branch. At or around the time that I release that version, I create a separate branch (from master) for that version. This separate branch is used to create dot releases. After I create and release a new dot version, I merge those fixes into the master branch. This would result in a mess if the documentation, RPM .spec files and moduleversions file were kept in the same (/code) repository. I use cherry picking in the case where I decide to include a commit from the next release (commited in the master branch) in a dot version, because I only want that single commit. Going forward, it is probably desirable to create the release-specific /code branch when we begin working on that release. We can then push changes in that branch to GitLab where they will appear as merge requests. We can do the same for the /release branch: a) Provide a known_problems file that only includes the first two items (those will never be fixed). b) Move the Problems Corrected and New Features section contents down into the 'Prior Versions' section and leave those sections empty. c) Update the heading with the new version (the release date will be changed at the time that the final build is done). Builds will automatically use the release-specific branches if they exist. If either does not exist, the master branch is used. HTH, -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \_______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
