undefined | Better HN

0 pointsNickLarsen13y ago0 comments

This is exactly the pain my advice helps you avoid. The implicit cost of creating a fork is that future changes higher up the chain could either cause you to be stuck at this revision or give you an additional bulk of work in order to update. Of course anyone can update and run a custom build for their project, but the cost is often not worth it.

It should be noted that the situation where you intend to fork and maintain the project, this does not apply, and by all means make your changes. In the case where you intend to update, this pattern will help you avoid the pain.

0 comments

cromulent13y ago

So, where you intend to fork and maintain, then fork and maintain.

If you do not intend to fork and maintain, then do not fork and maintain.

Is that what you are saying?

NickLarsenOP13y ago

Yes, with a strong bias to not forking and maintaining. Stale project, well you gotta fork and maintain. Active project, avoid forking with the intention of using a custom build in your system.

EGreg13y ago

Nick - it's just different levels. One can say the same thing about future versions of libraries not maintaining backward compatibility, and breaking APIs that applications depend on. So does this mean you should never download upgrades of libraries that your apps depend on?

The way I see it there are there levels in a good stack:

1. CORE 2. MODULES 3. APPS

Ideally, the thing should be extensible enough that the module writers can respond to changes in the core but keep their own API backward compatible. There are fewer modules than apps, and there is only one core.

So I think the whole argument isn't black and white, it's a matter of degree! Things have to get done, and sometimes things change. That's the only constant, you know :)

j / k navigate · click thread line to collapse