Hacker News new | past | comments | ask | show | jobs | submit login

TBD is fine for web apps, but not for software that you have to maintain multiple versions in the wild at the same time or when the release cycle takes several weeks.

That isn't true at all. Trunk based is perfect for this because you have the clean release branches from the trunk.

I've worked in large companyies very successfully using TBD and releasing quarterly to enterprise customers using our software on their systems.

> I've worked in large companyies very successfully using TBD and releasing quarterly to enterprise customers using our software on their systems.

care to elaborate? curious about those companies and the software you are talking about.

i totally see the trunk based process work for software that doesn't need to maintain multiple versions as the original commenter said.

but for multi-versioned software you can't afford to have a single trunk and let your developers have a go at it. i went and checked the repos for some of the multi-versioned software that i use that are open-source.

well confirmed.

Why do you need to maintain multiple versions? You should only need to maintain hotfixes on the last release branch. Once the next release is ready everybody who can update should take that release, any older releases become unsupported.

From a customer point of view a hotfix vs new release should be no difference. You just have to ensure that all releases are interface-compatible with the previous one. The cost of this is well worth it compared to the complexity of juggling multiple branches in parallel.

I think I understand your point, but thinking about releasing a hotfix over an old version is a way of maintaining multiple versions... I work once with a team supporting multiple versions of a really complex app(in the sense of a lot of features and DB entities). They support his clients (on-premises) with eventual hotfixes, one service-pack and one version a year.

Some times they were working on changes on a release before a hotfix was addressed, and with cherry-pick's like operations, they took the changes of the hotfixes and applied to the service-pack and new versions with less effort than before they used the model.

With a dev team of 10 programmers, 20 on IT support and hundreds of client's deployments they build a profitable business (subscription-based and in-site support) where the branching model helps a lot.

They spend less time managing the releases, switching context for priority support and dealing with more changes in less time.

At the top of this thread is a link to a clear explanation in a post by umvi. Very easy to understand.

So...shouldn't the focus be fixing the fact that release cycles take several weeks?

This is well researched and discussed in Nicole Forsgren's book: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations


Sometimes long test cycles are just the nature of the business, especially in hardware-software co-development, and especially in high-reliability development. Nobody will believe that running software tests on a workstation or server somewhere counts for release readiness if it gets deployed to a wind turbine, robot, or megawatt UPS.

The software team's automated tests indicate that the software is ready to start an expensive physical testing cycle, not that its ready to go to the field.

More accurate to say gitflow is fine for webapps. TBD is broader than gitflow, and i agree that when you have to maintain multiple versions in the wild, i would not use gitflow.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact