4 ms·
Can you (or somebody) explain how that works in practice? Here I am ready to deploy some new feature to gmail. In the meantime, I'm getting a steady stream of
by RogerL 11y ago
Can you (or somebody) explain how that works in practice?
Here I am ready to deploy some new feature to gmail. In the meantime, I'm getting a steady stream of API changes. Can I build and release gmail to a specific revision number, and only incorporate the changes when I am ready, or are all release essentially off of the tip of the tree.
I don't need specifics, just the general idea. Where we work basically every project lives in its own branch, which makes it essentially impossible to synchonize changes. Things have to get merged to trunk, then pulled into the appropriate branch, and I don't like it at all.
Do you have version numbers for libraries/components: projext X uses version 1.5.4 of Y, 32.4.18 of Z, and so on, do you pull by revision number, are you all on tip?
It'd be very interesting to hear how you manage this.
- pacala 11y agoEvery feature has a flag that you can turn on/off to your heart content. Releases are cut at head. No need to use the version control hammer to screw all the zippers.
- randyrand 11y agoWould that be analogous to, every feature is it's own git branch? and you choose which branches to merge when building? How are conflicts managed?
- electrum 11y agoNo, features are configurable at runtime. This allows A/B testing or slowly rolling out a new feature. Depending on the type of change, you might test it on 1% of users, 1% of servers, etc.
- pacala 11y agoEvery feature is in HEAD, behind a flag. Precisely because managing conflicts cannot be automated, relying on branching is unwise. With HEAD based development, you manually solve conflicts exactly once, when submitting to HEAD, then you never have to think about them again. Local branches for development, a single HEAD for merging code.
- wsetchell 11y agoIn theory: Everyone works from head, so there is only one version of everything. When you write a feature, you follow these steps. 1. Write code and submit to the main (and only) branch. Hide your feature behind a flag. 2. Releases happen from head (with no regard to your feature) 3. When you want to enable your feature, you flip a flag to turn it on. In practice: Things are messier.
- Nitramp 11y agoYes, you sync you workspace to a particular revision and work within that. Syncing is a manually triggered process. And generally speaking, people changing APIs are required to find and fix all users (which isn't that hard with the infrastructure available). There is still some churn created by the constant stream of changes, but it's usually not on the changing APIs level.