Open jeremystretch opened 1 year ago
For my two cents: Removing or renaming the "master" branch makes sense. The "master" branch not being the one being actively developed was confusing for me as a newcomer as well.
That said, I'm not sure how much value there is to squashing the commits on the "release" branch. Is the efficiency really worth not being able to "git blame" if you have the release branch checked out? Personally, I'd say no, I'd much rather have git blame work if I'm checked out with the release branch rather than have my checkout take half a second instead of three.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.
Proposed Changes
We currently maintain three persistent branches within the project:
master
- Contains the latest stable releasedevelop
- Any work intended for the next patch releasefeature
- Feature work & breaking changes intended for the next minor release (e.g. v3.6)The
master
branch is essentially a clone ofdevelop
, which gets merged every time a new release is to be published. We can remove this branch and create a newrelease
branch which contains only a single squashed commit for each release.Justification
Our current approach can be confusing as many newcomers expect
master
to function as the repo's default branch (ours isdevelop
). And introducing a newrelease
branch which is limited to only squashed commits provides a much more efficient mechanism for checking out the latest stable release using git (e.g.git checkout release
).