One of the major functions of any open source project is releasing software, with the goal of reaching as many users as possible. To help our projects succeed, we need to ensure that we get the message out in a timely fashion, to the widest relevant audience, and with the right information.
With that in mind, we've crafted a set of guidelines for coordinating release announcements to ensure that your excellent work doesn't get lost in the shuffle. Remember that these are only guides; your own community practices can be different.
General Guidelines
- Do not set any release date for a Friday or significant holiday. The ideal release date for maximum coverage is Tuesday.
- If at all possible, coordinate major releases with relevant conferences and events.
- Tailor release announcements and blogs to encourage use of software as well as contributions to project.
- Talk about how a project benefits the user, explain the benefits rather than focusing on technical details.
Track: RC and Final Release for Major Point Release X.0
No less than three weeks from release date:
- Create a collaborative document (Etherpad, Google Doc) to include highlighted features for the release announcement, press release, and blog.
Two weeks from release date:
- Generate a changelog that includes notable changes to the release that will need to be documented and included within the main changelog file.
- Merge any relevant content from the updated changelog into the release announcement, press release, and blog.
- Create press release and send to PR for vesting
One week from release date:
- Have social media content in place for scheduled/live distribution before, during, and after release date.
Three days from release date:
- Release manager, engineering lead sign off on release announcement and blog.
- PR signs off on press release.
Two days from release date:
- All final QA/smoke tests should be completed.
- Build should be placed on appropriate servers.
One day before release date:
- Relevant media outlets should be sent copy of press release.
Day of release:
- Code should be made visible to outside world.
- Release announcement, social media, and blog should be published as scheduled.
- Press release should be posted on newswires via PR.
Track: RC and Final Release for Point Release X.Y
No less than 2 weeks from release date:
- Create a collaborative document (Etherpad, Google Doc) to include highlighted features for the release announcement and blog.
One week from release date:
- Have social media content in place for scheduled/live distribution before, during, and after release date.
- Generate a changelog that includes notable changes to the release that will need to be documented and included within the main changelog file.
- Merge any relevant content from the updated changelog into the release announcement and blog.
Two days from release date:
- Release manager, engineering lead sign off on release announcement and blog.
- All final QA/smoke tests should be completed.
- Build should be placed on appropriate servers.
Day of release:
- Code should be made visible to outside world.
- Release announcement, social media, and blog should be published.
- Relevant media outlets should be sent copy of release announcement.
Track: Final Release for Minor Point Release X.Y.Z
No less than one week from release date:
- Have social media content in place for scheduled/live distribution before, during, and after release date.
- Generate a changelog that includes notable changes to the release that will need to be documented and included within the main changelog file.
- Merge any relevant content from the updated changelog into a release announcement.
Two days from release date:
- Release manager, engineering lead sign off on release announcement.
- All final QA/smoke tests should be completed.
- Build should be placed on appropriate servers.
Day of release:
- Release artifacts should be made visible to outside world, if they are not already. (It's okay if a release is synced to mirrors ahead of the actual release announcement.)
- Release announcement and social media should be published.
After All Major Releases and Significant Point Releases
- Post-mortem follow up should be done to see what, if anything, could be done to improve the next release cycle.
Sample Press Release/Release Announcement
Pushing out a release announcement would seem to be relatively straightforward, but in order to get the most impact from your announcement, it should be written in a way that's going to be most likely to be picked up by the media.
Here, then, is a template for a release announcement, with some guidelines. Please note, this is a guide only, and boilerplating exactly what we have here may not be effective for your project.
Be matter-of-factual about information shared in public statements. Avoid hyperbole ("the bestest project ever made!!!" and speculation ("the only project that can do this"). As tempting as it is, release announcements should not opportunities to hype your project. You can take the opportunity to thank your hard-working community, however; this not only gives credit where credit is due, but also emphasizes the free and open source nature of the project. Media outlets will rapidly disregard such hyperbole and possible avoid spreading the word about your release altogether.
Be clear, concise, and use facts and supportable information. This will help get your announcement more broadly disseminated.
--
Project X, the [main purpose of project: goals, functions, governance] project, today announced the general availability of Project X x.y, a community-driven [description of project]. This latest community release includes several new features, including [list of newest features].
Developed by a global community, Project X [a detailed paragraph of what the project is, what it does, and any other pertinent information should be included here.]
Notable enhancements to Project X x.y include:
- [Detailed paragraph describing a first major feature]
- [Detailed paragraph describing a second major feature]
- [Detailed paragraph describing a third major feature]
A complete list of Project X x.y features is available on the Project X community release announcement page [URL]. Project X x.y [detailed description of a two or three additional features].
[If possible, add a quote from a prominent community member or technical lead about the new release here.]
Additional Resources
- Read more about the Project X x.y release highlights [URL]
- Get more Project X updates on Twitter [URL]
- Read more about Project X community events [URL]
About Project X
Project X is [a very detailed description of what the project is and what it can do].
저자 소개
Brian Proffitt is Senior Manager, Community Outreach within Red Hat's Open Source Program Office, focusing on enablement, community metrics and foundation and trade organization relationships. Brian's experience with community management includes knowledge of community onboarding, community health and business alignment. Prior to joining Red Hat in 2013, he was a technology journalist with a focus on Linux and open source, and the author of 22 consumer technology books.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.