Brave new (1.0) world.

[Geoffrey Broadwell]

On Thu, 2009-02-19 at 13:33 -0500, Will Coleda wrote:
> If we're calling 1.0/1.5/2.0 -milestone- releases, then they should
> actually be milestones. [1]

Strongly agree.

> If 1.5 is released in July 2009 regardless of what's in the release,
> then calling it a milestone release (and giving it a special version
> number to note the fact) is misleading.

Yes.  But I've got a thought on that "special version number" at the
end.

> If that's the intent, then I
> would recommend dropping the version numbers and just calling it
> "200907".

I don't like this as much as your next idea:

> I would rather see the feature set required for milestone releases be
> fixed (or at least fairly firm), have monthly releases of the 1.0
> milestone branch occur until 1.5 is ready to ship, and then update the
> release date to "whenever it happens.".

Mostly agree.  But I'd call the feature set a "thick slush" -- if an
unexpected major feature makes it in, but an expected one does not, I
still consider that worthy of a milestone.

> [1] equivalent to the pre-PDS world where going from 0.7.1 to 0.8.0
> (e.g.) indicated we'd actually changed something major, but if we had
> gone to 0.7.2 instead, it would have indicated only minor updates. the
> release still occurs monthly, but features drove whether or not it
> made sense to consider it a milestone release or not.

Agreed.  I strongly believe in the fixed monthly release cycle, and I
generally like having a "significant" release every 3 or 6 months, but
as for the "milestone" releases, I don't like a situation in which we
are:

  * Staffed by volunteers, most working for free when they can get time
  * Promising a list of features for milestones well in advance
  * Fixing milestone release dates in stone

And thus:

  * Setting ourselves up for yet more PR troubles every time
    we release a fixed "milestone" that doesn't meet our promises

As far as the "special version number" issue goes -- I've always thought
it strange that y'all decided to alternate '.0' and '.5' minor numbers
every 6 months, but treat them exactly the same in terms of release
expectations (they're all "milestones").  To me, there's been a
conflation between deprecation boundaries, support windows, and
functional milestones.  I can understand the desire to keep all of them
on the same schedule, but I don't see it working all that well with all
volunteers.

How about a three part number, as follows:

  1. Milestone
  2. Deprecation boundary and/or longer term support release
  3. Monthly release

#1 and #3 increment by one each time; #2 can be incremented by whatever
we think is a good marketing amount.  So let's say we wanted to keep the
6-month cycle on "significant" releases, but were late on the first
milestones, on time on the second, and early on the third.  The
numbering would be:

  1.0.0
  1.0.1
  1.0.2
  1.0.3
  1.0.4
  1.0.5

  1.1.0  or  1.2.0  or  1.5.0
  1.1.1      1.2.1      1.5.1 
  1.1.2      1.2.2      1.5.2
  2.0.0  # MILESTONE late
  2.0.1
  2.0.2

  3.0.0  # MILESTONE on time
  3.0.1
  3.0.2
  3.0.3
  3.0.4
  4.0.0  # MILESTONE early!

  4.1.0  or  4.2.0  or  4.5.0
  4.1.1      4.2.1      4.5.1
  ...


-'f