Omni Core 0.0.10 release plan

release_plan-0.0.10_checklist.md

• Finalize Omni Core (2015-11-04)
• Tag the release candidate on GitHub as "0.0.10-rc1" (2015-11-04)
• Build and sign binaries via Gitian (2015-11-06)
• Tag the second release candidate on GitHub as "0.0.10-rc2" (2015-11-11)
• Build and sign binaries for second release candidate via Gitian (2015-11-11)
• Upload release candidate binaries (2015-11-11)
• Announce release candidate on "dev" mailing list (2015-11-11)
• Discuss draft for download page
• Publish blog post (2015-11-14)
• Test and evaluate the release candidate
• Tag and release release on GitHub as "0.0.10"
• Upload release binaries
• Publish download landing page for release
• Publish blog post about release
• Announce release on "dev" mailing list
• Announce release on "announcements" mailing list
• Announce release on social media (e.g. Reddit, bitcointalk.org, ...)

release_plan-0.0.10_details.md

1. Finalize Omni Core

After the review of the release notes, merge #273, #269 and #162, which finalizes the code work.

It depends on your participation.

2. Tag the release candidate on GitHub as "0.0.10-rc1"

This can be done immediately after the previous step.

3. Build and sign binaries via Gitian

Primarily a task for zathras and dexx, which roughly takes 3-12 hours.

4. Tag the second release candidate on GitHub as "0.0.10-rc2"

Due to the release of Bitcoin Core 0.10.4 a second release candidate needed to be schedueled.

5. Build and sign binaries for second release candidate via Gitian

Primarily a task for zathras and dexx, which roughly takes 3-12 hours.

6. Upload release candidate binaries

The landing page for downloads is not yet needed, as it's only the release candidate (not intended for full blown public release).

The uploads should be hosted on downloads.omnilayer.org.

7. Announce release candidate on "dev" mailing list

The release candidate should not yet be announced on the "announcements" mailing list, but only on the developer list, as it's not yet intended for use in production.

8. (or so) Discuss draft for download page

Given that there is some waiting period between release candidate and the actual release, this is probably a good time to finalize the download page for the release.

9. (or so) Publish blog post about activation mechanism

Ideally this is done before the actual release is out.

10. Test and evaluate the release candidate

Minimum acceptance criteria to be satisfied on native target systems (Ubuntu, Windows, OS X - CI servers don't count):

Windows:

• pass unit tests (2015-11-11)
• pass integration tests (2015-11-11)
• sync up to the current chain tip, and pass checkpoints (2015-11-10)
• no segfaults or non-recovering hungs inbetween (2015-11-10)

Ubuntu:

• pass unit tests (2015-11-12)
• pass integration tests (2015-11-12)
• sync up to the current chain tip, and pass checkpoints (2015-11-132)
• no segfaults or non-recovering hungs inbetween (2015-11-13)

OS X:

• pass unit tests
• pass integration tests
• sync up to the current chain tip, and pass checkpoints (2015-11-21)
• no segfaults or non-recovering hungs inbetween (2015-11-21)

The more testing and playing around with the release candidate, the better, especially since there is the daemon and the GUI client.

dexx can cover Ubuntu and Windows, but he has no access to a Mac. Maybe Sean can tackle this?

If any serious issue is found, then the fixing begins and a third release candidate needs to be schedueled. Otherwise:

11. Tag and release release on GitHub as "0.0.10"

This presumes no more issues are unresolved.

12. Upload release binaries

13. Publish download landing page for release

14. Publish blog post about release

15. Announce release on "dev" mailing list

16. Announce release on "announcements" mailing list

17. Announce release on social media (e.g. Reddit, bitcointalk.org, ...)