I think "Week number" is too ambiguous to be a guide. If January starts on the last day of the week, does that still count as week#1? What day does the week start on, anyway--much of the world starts the week on Sunday, much of the world starts the week on Monday.
"Fourth Tuesday in January/July" is unambiguous and makes everything easier to plan. Using "Start + N weeks" for the rest of the target dates is fine.
The whole table is meant to be a guide and not exact. I like having the approximate calendar dates, because I think this is the most informative for non-release managers. The week numbers are really meant for the release manager, but I would be fine replacing those with deltas (e.g. + 4 weeks) if you think that made more sense.
I'd expect the pace of preparing the release to be basically the same regardless of start date, so the milestones would make more sense as start date plus N weeks.
If you want wiggle room for the start date, that's fine, anything that expresses "late January" and "late July" will work. I thought it was going to be more definitive, what with specific week numbers and all.
It's helpful for the release managers to have at least have a target date for creating the release branch and also to know how much time to wait between -rc1 and -rc2. I think we should have this information at a minimum, but I agree after -rc2 the release schedule does become unpredictable. I'll try to rework this, so it is less specific.
Actually, I'd prefer relative Tuesday for both processes. Otherwise we'd eventually start on weekends...
First date is relative to month (4th Tuesday) and the following are relative to first (2 weeks later, etc).
Specific dates make no sense to me.
I'd also say "at least N weeks", perhaps even also "at most N+M weeks". Having specific dates or non flexible time frames will cause people to complain on the list when things don't go according to plan, pointing out our documentation and saying, with reason, that we're not following it.