Oddbean new post about | logout
▲ ▼
mleku | 16 hours ago (raw) | root | parent | reply | flag +1 
 IMO, the main/master/dev branch should always be the default one, and fixes and features should be marked by tags, that's how i do it

but some think of the master/main as some kind of precious that you only update every few months

not putting the main work on the default branch makes a repo look ded, and it's stupid doing that, branches are not where you make releases, you have tags for releases ffs lol
▲ ▼
ChipTuner | 4 hours ago (raw) | root | parent | reply | flag 
 When the dev updates the default branch I expect to be able to pull it and have it build without failing. My staging branches will never be 100% stable for every feature merge. When it's stable and features are merged, then the default branch is updated. Many times a project's features or fixes take a really long time to get tagged, so pulling the latest tag can be months old, while pulling the latest default may have fixes, so it should compile, period.
▲ ▼
mleku | 4 hours ago (raw) | root | parent | reply | flag 
 that's the conflict, between the "main is the release" and "main is the unstable development" because it's the most visible, if you only allow stable releases on it, the activity you see on the main page of the repo is very slow and seems like nothing is happening

building in public is a key part of the social engagement of open source development and for that reason, the consensus is moving towards unstable mains, and forget main, call it "dev" or "development" so it's clearly unstable, and mark milestones on tags, which can be combined with "releases" when a minor or major version bump happens, build out binaries or whatever as the case may be, package APKs etc

the main branch SHOULD always build though, when i say development i don't mean unstable as in can be not working but unstable as in, may have bugs still until those are fixed and put into a tagged release with a version number

for reasons of how the Go toolchain looks for the newest release or newest tag, it's also important for developers with libraries because the tags are easy to remember and you can write them straight into the module file (like a package.lock, but sorta like a package.json but it's neither)... anyway, the same thing can be applied, not so automatically, with other languages, but yeah

i agree that it should build on the main branch, i just don't agree that it should necessarily be working, and that this is what tagging is for

side branches make sense only with a very large project and teams of more than about 4-5 developers, and the first level of them usually will be platform targets more so than features... again it depends on the size of the team, two guys on a project mostly you can just work on a branch that's your branch and then merge them up to the development branch when they are building and kinda runing, and when the features are stable, you tag a minor version bump, otherwise, tagging patches for potentially unstable changes, so they can be easily referred to