Build Debate: Followup on Build Naming

[Jim Gettys]

Actually, it is a bit more complicated; whether we should reflect this
in numbering, is, however, less clear to me.

We have network protocols in the presence service we depend on, and
which fundamentally affect interoperability between applications ("flag
days").  I also posit we're very likely to have to face at least one
more flag day before we reach long term stability in these protocols.

Changes to these protocols *may or may not* involve binary changes to
activities; sometimes these will, and sometimes libraries may hide them
and they not be visible to the activities (though very visible to the
person using the aggregated system).

So since this seems to be a long winded discussion, I wanted to point
this out; even if I don't have a proposal for a numbering scheme.
                              - Jim

On Tue, 2008-04-08 at 14:30 -0300, Martin Langhoff wrote:
> On Tue, Apr 8, 2008 at 11:38 AM, Walter Bender <walter.bender at gmail.com> wrote:
> >  As far as a feature-based scheme, that will just increase the pressure
> >  to do an end-run around our renewed pledge to do time-based releases.
> >
> >  I'm in favor of Dennis's suggestion. OLPC-1; OLPC-2, ... It is simple
> >  and, I argue, unambiguous. The hardware is XO-1, XO-2...
> 
> I generally agree but rather than just incrementing numbers, we can
> use the opportunity to use it to communicate api, stability and
> feature deltas. After having worked in projects with many schemes, I
> find that the best communicator is  a 3-part release name x.y.z
> where...
> 
>   - X is the "major" release name. Many projects stay in 0 until the
> first feature-complete/stable-api release comes out the door to claim
> "1".
>  - Y is the minor feature incremental version
>  - Z is the bugfix level
> 
> So
>  - 0.3.2 means we are on our way to feature-complete, this is the 3rd
> add-feature release, 2nd bugfix release
>  - 1.0.4 is the release you want to put on machines in a country with
> areas so remote that you can only visit for an upgrade every 2 years
>  - 1.5.0 means we are on a stable api, 5th feature release, just
> issued. Conservative people may wish to wait until 1.5.2 for example,
> unless something in the 1.5.0 changelog is a "must have" feature.
>  - 2.0 means some APIs have changed, your Sugarized app is very likely
> to break.
> 
> While we crank out builds and while in development we can call them
> anything, the important thing is the label on the release. It is the
> most succint means of communication with decision-makers, big and
> small. As such it should be a clear indication of what kind of things
> I'll find in the changelog, specially for those users that will not
> read the changelog.
> 
> cheers,
> 
> 
> 
> martin
-- 
Jim Gettys
One Laptop Per Child