> On Oct 31, 2016, at 12:22 PM, Russell Bryant <russ...@ovn.org> wrote: > > > > On Mon, Oct 31, 2016 at 5:23 PM, Justin Pettit <jpet...@ovn.org> wrote: > >> > On Oct 29, 2016, at 9:19 AM, Russell Bryant <russ...@ovn.org> wrote: >> > >> > + >> > +The following table identifies the planned dates for upcoming release >> > +milestones. >> > + >> > +| Release Milestone | Approximate Date | >> > +| ------------------------------ | ----------------- | >> > +| branch-2.7 created | Jan 11, 2017 | >> > +| 2.7.0 released from branch-2.7 | Feb 8, 2017 | >> >> I'm fine with jiggering our release schedule for 2.7. However, this changes >> from a formula-based table to one specific to 2.7. Is there a reason you >> didn't just adjust the dates in the original table? I'm hoping that we >> won't be shifting the dates all that often that we'd need to update the >> documentation for each release. >> > I was thinking we'd update this for every release. We'd be aiming for six > months, but we'd pick specific dates each time, after looking at alignment or > conflicts (major holidays, events, other project schedules, ...). Another > reason was that I was proposing a shorter time between branch-2.7 creation > and release for the shorter release cycle, so it didn't fit the formula. I > don't mind changing the table back, but then I'm not sure where to document > the proposed deviation from the formula for 2.7.
I understand the logic, but I think if we update it every release, it won't give people much confidence that there's a regular release cadence--even if we do adhere to it. There's already some wiggle-room in the dates, so I wouldn't expect holidays and other events to cause us to miss the deadlines by much. In terms of the 2.7 release, I think the commit message does a fine job of explaining why the dates were modified. --Justin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
