Some of what I have said above may be a function of team size (we have few programmers). In a bigger team we would probably have to do some stuff differently, but I doubt my preferred approach would match what you see commonly.
-
-
Replying to @Jonathan_Blow @meglio and
Re Steven's point about the cost of branching, I would say that the whole idea of branching assumes you are in an environment where productivity is low relative to the size of the code base. As productivity rises, branches make increasingly less sense.
4 replies 0 retweets 16 likes -
Replying to @Jonathan_Blow @meglio and
I’d add to all of this, branches *are* useful if you need to maintain multiple live versions of your software. That’s typically not the case for games, web things or (most) apps, but enterprise software, operating systems and so on do have that problem.
1 reply 0 retweets 0 likes -
What do you mean? All high-end games do this as the platforms we ship on are all very different and we need to support them post-release. Branches would be an awful way to do that.
2 replies 0 retweets 6 likes -
Replying to @Jonathan_Blow @meglio and
For enterprise software and operating systems, you can’t release updates containing unexpected new code. You pretty much have to branch. Feature flags just aren’t sufficient. (Reality can be quite complicated; e.g. some sub projects might be able to use feature flags.)
1 reply 0 retweets 1 like -
Replying to @al45tair @Jonathan_Blow and
What's "unexpected" code? If the argument is that OS's and enterprise software is too complicated to handle without branches I mean, yeah... shit is at least an order of magnitude too complicated to handle WITH branches which is kind of the problem all over.
2 replies 0 retweets 3 likes -
Replying to @StevenBHutton @al45tair and
I think this approach can be done to effect with large teams on large games where I have some experience. But I have no experience working on huge OS projects. Maybe they HAVE to branch but I'm skeptical.
2 replies 0 retweets 3 likes -
Replying to @StevenBHutton @Jonathan_Blow and
And as for OS projects, there’s usually a whole other layer over and above “normal” VC. You can see this with the Open Source Linux distos - they have package managers and each version of their distribution has different sets of packages. All have to work together.
2 replies 0 retweets 0 likes -
Replying to @al45tair @StevenBHutton and
Those package managers all look to me like a giant disaster, and the first order of business should be to eliminate all of it. So if you are using that as an example of how to do things well, I am not riding that train.
2 replies 1 retweet 21 likes -
Replying to @Jonathan_Blow @al45tair and
Separately, there was no acknowledgement or rectifying of failure of terrible ideas that were pushed specifically to avoid things like this. So, COM is still here, which was supposed to "solve" the versioning problem, but we _also_ now have package managers. It's truly insane.
2 replies 0 retweets 14 likes
At this point I have lost count of all the things that are supposed to "solve" this problem. Branches, DLLs, COM, sxs assemblies, package managers, appcompat, VMs, Docker... I mean at some point somebody should acknowledge that this has been an epic disaster.
-
-
Replying to @cmuratori @Jonathan_Blow and
Well, and all of this only to pretend that the solution ISN'T mostly "we actually need competent people to take responsibility and do their job properly" No, instead, just throw tech stack after tech stack on the same problem.
2 replies 0 retweets 5 likes -
Replying to @skore_de @cmuratori and
And now, AI is supposed to be the thing that will finally mean that programmers can justify not doing their damn job properly.
1 reply 0 retweets 3 likes - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.