GNOME Release Planning Timeline

An attempt to cover recurring r-t tasks in the release cycle. Feel free to add tasks.

NOTE: To merge with https://live.gnome.org/ReleasePlanning/Tasks/ByTime that I could not find when I created this.

To merge/move under https://live.gnome.org/ReleasePlanning once a full release cycle is covered.

About eight weeks before stable major:

  • Make sure that gnome-i18n and gnome-doc-list know about new modules/applications planned to get into the next release (for 3.2, it was unknown for a too long time that e.g. sushi, gnome-documents and gnome-contacts are expected to be shipped by default)

About four/five weeks before stable major:

About two weeks before stable major:

A few days before hardcode freeze:

  • Send list of bug reports with patches with status accepted_commit_now to d-d-l (3.1 example)

  • Announce feature proposal period on d-a-l (3.3 example, 3.5 example)

  • After r-t feedback, announce schedule draft for next release cycle (3.3 example) on d-d-l (3.3 example)

  • Update/upload schedule ics file: git checkout releng, go to tools/schedule/, run ical.py after setting the file to "3.6.schedule" inside the script, and after testing locally in Evolution's calendar upload the output to static-web/tree/calendars/schedule-unstable.ics

Under hardcode freeze:

  • Review break request like mad.
  • Sort out if anybody will provide live images

Directly before major release:

Sync with marketing: https://live.gnome.org/GnomeMarketing/ReleasePlanning

After major release:

After Feature proposal freeze:

After .2 release:

  • Bump the minimum required GNOME version for bug reports submitted to GNOME Bugzilla via bug-buddy to previous-major.0 and announce it on gnome-bugsquad.

AndreKlapper/ReleasePlanningTimeline (last edited 2015-04-23 16:12:51 by AndreKlapper)