[OPEN-ILS-GENERAL] 2.8 release scheduling

[Ben Shum]

Moving towards a more solidly time-based release has been a constant
challenge, but predictably having a March / September (not October,
heh) with a beta cut-off a month before actual RC and release seems to
lay out the timeline pretty thoroughly.  With some minor wiggle room
applied by each release manager as they see fit based on what's
actually happening at the time.  I've been thinking about raising the
idea of setting rough milestone objectives for the next whole year
ahead of time so that there aren't any surprises about this,
regardless of who's elected RM (and especially if the election of the
RM takes longer and cuts into the 6 months allotted for each major
release).

Having an interval of time between cutting the first beta and
stabilizing things post-merge sounds like a very smart idea.  I ended
up doing this by accident (or on purpose?) with my own one week delays
in cutting releases after announcing business closed on merging.
Officially the dates were listed out for 2.7, but unofficially, I
ended up spending the follow-up week bug fixing / testing last details
before actually cutting the releases.  Having the time table
established and announced this way lends more time for the broader
community to participate in the testing process that we should be
encouraging to occur.  So I'm +1 to keeping this concept in place, if
perhaps making minor adjustments to the dates.

As far as pushing back the mid-March release date, that's not
something I'm opposed with doing.  Community-wise, we've never made
any explicit promise for a release to occur by middle of the month,
it's just nicer that way.  That said, these are almost arbitrary lines
in the sand sometimes.  No matter what date we suggest, we'll still
end up with unfinished, hanging threads that need to be cut and moved
on to the next major milestone.

That said, whenever we schedule the next developer meeting (maybe
January now?), I think I'd like to re-raise the idea of evaluating
whether March/September has worked out well for the major release
months of the year.  For myself, I still like the idea of
April/October.  But again...arbitrary lines in the sand.  :)

-- Ben

On Thu, Dec 18, 2014 at 12:11 PM, Bill Erickson <berickxx at gmail.com> wrote:
>
> On Thu, Dec 18, 2014 at 8:29 AM, Mike Rylander <mrylander at gmail.com> wrote:
>>
>> Bill,
>>
>> First, thanks for putting out a timeline.
>>
>> I am a little concerned about the pre-beta feature freeze.  In the past,
>> the merge deadline for features has always been "whatever makes it into the
>> beta release", and I don't see cutting that back by a week helping things to
>> get done faster -- we just end up with a week less features in 2.8, and that
>> last week is often (us being humans, and whatnot) the critical push time for
>> things that are almost there.  Do you have something in mind that I'm not
>> seeing for the change there?
>
>
> The feature freeze basically is the beta.  (I recall now this was called the
> "beta cut-off" during the 2.6 cycle.  I'll use this terminology going
> forward).  The interval between the cut-off and beta release cutting is our
> chance to let the dust settle after the merge rush so we're not cutting a
> buggy beta.  If Feb 18th is too soon, we can certainly push the beta back.
>
> With my proposed schedule, the post-freeze period for 2.8 is already 2 weeks
> shorter than it was for 2.7.  So, if we push the beta back, we should push
> back the mid-march release date as well.
>
>>
>>
>> I did note that the feature target deadline is not a hard deadline, but
>> for my part I can say that with the schedule only being clarified over what
>> amounts to 3 months (the remainder of December through release in
>> mid-March), the middle of January will be a tight squeeze to target things
>> by then.  Being one that does a good bit of feature development, I expect to
>> be begging leave to target features after the scheduled date on several
>> smaller features, as dev time permits in January and February.  I just want
>> to set that expectation now, so it's not a surprise if it ends up
>> happening...
>
>
> I am definitely expecting new features to emerge after the LP target
> deadline.  This deadline serves two purposes in my mind.  1. If you know
> about it, document it, so others will know about it.  2. If you want to
> introduce large architectural changes after this date, be prepared for
> additional community scrutiny.
>
> I was in no particular rush to publish the schedule with the assumption that
> release schedules are highly predictable.  Release mid-March/October, beta
> cut-off a month before that, and everything else is gravy.  For my own sake
> and that of future RM's, is that not a reasonable assumption?
>
> Thanks,
>
> -b
>
>
>>
>>
>> Thanks!
>>
>>
>> --
>> Mike Rylander
>>  | President
>>  | Equinox Software, Inc. / The Open Source Experts
>>  | phone:  1-877-OPEN-ILS (673-6457)
>>  | email:  miker at esilibrary.com
>>  | web:  http://www.esilibrary.com
>>
>>
>> On Fri, Dec 12, 2014 at 4:07 PM, Bill Erickson <berickxx at gmail.com> wrote:
>>>
>>> Hi All,
>>>
>>> I'm attempting to sketch out the release schedule for Evergreen 2.8, so
>>> I'd like to run some dates/thoughts by everyone.
>>>
>>> For starters, unless someone requests it, I'm not planning to cut an
>>> Alpha release.  I've never seen anyone install one :).  I'm happy to cut one
>>> if desired, though.
>>>
>>> Proposed schedule:
>>>
>>> * Jan 14 2015: Feature Target Deadline
>>>
>>> This is the date where all features we expect to get into 2.8 are
>>> documented in LP and targeted to 2.8.  They do not have to be coded or
>>> tagged as pull requests by this date.  They just need to be documented.  As
>>> before, this is a strong recommendation, but not a hard deadline.
>>>
>>> Feb 18 2015: Feature Freeze
>>>
>>> From this date forward, only bug fixes may be committed to master.  Any
>>> un-merged features will be booted to 2.9.
>>>
>>> Feb 25 2015: 2.8.beta1 Release
>>>
>>> March 9 2015: 2.8.rc1 Release
>>>
>>> March 18 2015: 2.8.0 Release
>>>
>>> Comments/suggestions welcome.
>>>
>>> Note that in the future I'll avoid cross-posting to both -general and
>>> -dev lists and just send 2.8 updates to -general to cut down on noise.
>>>
>>> Thanks, everyone.
>>>
>>> -b



-- 
Benjamin Shum
Evergreen Systems Manager
Bibliomation, Inc.
24 Wooster Ave.
Waterbury, CT 06708
203-577-4070, ext. 113