Resumen:
Abstract. SPL product customers might not always wait for the next core asset release. When an organization aims to react to market events, quick bug fixes or urgent customer requests, strategies are needed to support fast adaptation, e.g. with product-specific extensions, which are later propagated into the SPL. This leads to the grow-and-prune model where quick reaction to changes often requires copying and specialization (grow) to be later cleaned up by merging and refactoring (prune). This paper focuses on the grow stage. Here, application engineers branch off the core-asset Master branch to account for their products’ specifics within the times and priorities of their customers without having to wait for the next release of the core assets. However, this practice might end up in the so-called «integration hell». When long-living branches are merged back into the Master, the amount of code to be integrated might cause build failures or requires complex troubleshooting. On these premises, we advocate for making application engineers aware of potential coordination problems right during coding rather than deferring it till merging time. To this end, we introduce the notion of «peering bar» for Version Control Systems, i.e. visual bars that reflect whether your product’s features are being upgraded in other product branches. In this way, engineers are aware of what their peers are doing on the other SPL’s products. Being products from the same SPL, they are based on the very same core assets, and hence, bug fixes or functional enhancements undertaken for a product might well serve other products. This work introduces design principles for peering bars. These principles are fleshed out for GitHub as the Version Control System, and pure::variants as the SPL framework.