I first blogged about build options three years ago while still using APEX 3.x - I can tell by the green ;-)
I still use them regularly, but not often for versioning as they're allocated at a component level and not for attribute modifications - perhaps in later releases we'll see an extension of their use.
What I do see all the time is components with a condition type of "never". This is probably because it's the quickest way to turn off features that are broken or those you're not ready to completely remove for whatever reason.
The issue with this is they get forgotten. Future maintainers see these components in limbo and wonder if they should be removed or enabled, particularly if they lack comments regarding their status.
I have encountered valid circumstances when a report region is purposely set to "never" - where a link is available to export the relevant data as CSV.
Instead I would suggest creating a build option that looks like this:
The 'Status' of 'Exclude' means I don't see the components at runtime - just like a condition of "never".
'Default on Export' being the same as current status means it will stay excluded as the application moves between environments.
One major advantage I find is the accompanying utilisation report. At some point during the project I went through everything I've allocated 'to be removed' and decided if it truly was time to sent these components to /dev/null.
Do you have any interesting uses for build options?
I still use them regularly, but not often for versioning as they're allocated at a component level and not for attribute modifications - perhaps in later releases we'll see an extension of their use.
What I do see all the time is components with a condition type of "never". This is probably because it's the quickest way to turn off features that are broken or those you're not ready to completely remove for whatever reason.
The issue with this is they get forgotten. Future maintainers see these components in limbo and wonder if they should be removed or enabled, particularly if they lack comments regarding their status.
I have encountered valid circumstances when a report region is purposely set to "never" - where a link is available to export the relevant data as CSV.
Instead I would suggest creating a build option that looks like this:
 |
| Build option - to be removed |
'Default on Export' being the same as current status means it will stay excluded as the application moves between environments.
One major advantage I find is the accompanying utilisation report. At some point during the project I went through everything I've allocated 'to be removed' and decided if it truly was time to sent these components to /dev/null.
 |
| Build option utilisation report |