BIE uplift is about transferring BIEs that are based on the previous release of CCs to a newer release of CCs.
*Note that we decided to use the word uplift instead of upgrade to make it easier to distinguish from Score software upgrade.
https://docs.google.com/presentation/d/1tDn3ibjF9R3rSoPAZ1e6a6J3A9guyPZtGVNOb3qp_ps/edit?usp=sharing
Extension Copying
Extension copying means copying the underlying User Extension Group ACC (UEGACC - this is the ACC that encapsulates the added properties). This has to be copied first before info of BIE nodes in the extension can be copied.
What to copy? Here are possibilities.
Copy all the properties regardless of whether they are used in the BIE being uplifted.
Copy only properties used in the BIE being uplifted.
Copy properties used across all BIEs that share the same UEGACC and then can never be copied again when other BIEs are uplifted.
In 1b, when another BIE that share the same UEGACC is uplifted, things will be getting more complicated because another user might be changing that UEGACC, i.e., it is in WIP or QA state and it might have duplicate components so the application would have to carefully merge the properties. Regarding the state, the safe state to merge is WIP and ownership got transferred to the user doing the uplifting. So option 1a and 1c are more viable.
In future versions of Score, any End User CCs (EUCCs) used in the UEGACC have to be copied as well. This may not be very undesirable b/c they may not be needed in the new release.
It should be noted that after the first time UEGACC is copied/created, it will have to be put in Production state and Rev 1 in order that the corresponding BIE nodes can be copied. Once UEGACC is in Production state with Rev 1 and some BIE referencing it, only backwardly compatible changes can be made in future amendments (revisions).
So in my view blindly copying UEGACC and EUCCs into the new release kinda pollutes the new release.