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 DEFAULT_SCHEDULE in libschedule.py to "3.6.schedule", and after testing locally in Evolution's calendar upload the output to Infrastructure/static-web//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:

  • Add moduleset definitions for next version to jhbuild (3.3 example)

  • Update the redirect of https://www.gnome.org/start/unstable (example, sysadmin territory)

  • Update links with version numbers on https://live.gnome.org/ReleasePlanning

  • Update version numbers on https://live.gnome.org/Schedule

  • Finalize schedule draft:
    • Remove "draft" warning on the wiki (3.5 example)

    • Announce it on d-a-l (3.5 example)

    • Go to your git checkout of releng/tools/schedule
    • Make sure DEFAULT_SCHEDULE in libschedule.py is set to "3.6.schedule"
    • Run "./ical.py > 3.6.ics" to create the calendar file

    • Import the 3.6.ics file in Evolution to check if all went well
    • git add/commit/push the 3.6.ics file to the releng git module (3.5 example)

    • Copy ics file to Infrastructure/static-web git module and git commit/push it (3.13 example)

  • Send list of bug reports with patches with status accepted_commit_after_freeze to d-d-l

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 2018-08-31 15:36:25 by AndreKlapper)