Additional thoughts on this, from https://meta.wikimedia.org/wiki/Community_Engagement_%28Product%29/Process_ideas#Notifications_for_Beta_Features_.2F_More_deliberate_notifications (with minor cleanup)

• All users get notified each time a new Beta Feature is available, so they can try them out, make suggestions, highlight issues, and give other feedback
• All users get notified in advance each time an existing Beta Feature "graduates" to be on for all users, so they can give last-minute feedback and for awareness
• Users can opt out of these notifications if they aren't interested, but by default they're available to all for maximum feedback opportunities and awareness

• Perhaps we don't want to nag people about new beta features. They'd disable notifications with a "wth is this? I'm not tech-savvy" and never see them again.
• Instead of notifications, it could simply say the dates (when was it added to beta?) in the beta tab (and a "new!" red note perhaps).
• Or perhaps mention very very short summary of such recent news in the sidebar.

• Some design thoughts in this essay: m:On Tech Awareness

• This (and the beta tab itself) should be available to unregistered contributors too.

• Information about changes would be served to users, rather than needing to be found by users.
• Centralizing communications allows the WMF or volunteer development projects to inform users of changes whether at once or on a project per project basis

Advantages of Notifications for Beta Features

• Notify users of up-and-coming features, clarifying that the feature is incomplete and testing/feedback is requested
• Even if a user does not want to test or give feedback, they are made aware that there is such a feature/system/product in the works
• Users can opt out of these notifications if they really don't care about such things

• Proactively reaching users about changes helps communities to feel prepared for change or invited to participate in collaborate when notified of a beta feature launch or a "last chance to give feedback before deployment."
• Reduces need for users to go find information; brings information to communities

Disadvantages of Notifications for Beta Features

• Could be very spammy for low-stickiness users unless the notifications time out even if unread at some point (so you don't come back after 2 months away to find 12 notifications about software changes)
• Would be very spammy unless implemented as a proper cross-wiki notification type (so you don't get the notification on French Wikiversity, then on French Wikiquote, then on Dutch Wikipedia, then…)
• We currently can't do notifications for logged-out users (readers or editors), as the Notifications system doesn't support that
• Only works for code we can split off into Beta Features; not really possible for wider-reaching features like Flow (pages can opt in, users can't) or
• If implemented with nagging/popups/noise, people would close this off and get rid of this, and remain unaware of future changes.

• Could become noisy if the same systems that notify users of other events are used
• Could become annoying as in "one more notification system"

This really isn't a deployment systems task; all of the logic would live within MW or whatever extension manages this (eg: BetaFeatures). From a deployment system's perspective, every deploy that has new code has new features; it's all the same to us :)