From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-07-20 12:45:06
I think this is a very reasonable approach.
From: Beman Dawes <bdawes_at_[hidden]>
> At 12:40 PM 7/20/2001, Darin Adler wrote:
>
> >On Friday, July 20, 2001, at 09:18 AM, David Abrahams wrote:
> >
> >> From: "Beman Dawes" <bdawes_at_[hidden]>
> >>
> >>> I think that Boost Coding Guidelines should be accepted, but subject
> to
> >>> refactoring into separate "Requirements" and "Guidelines" documents.
> The
> >>> refactoring should include material from the current "Library
> >>> Requirements
> >>> and Guidelines" page, http://www.boost.org/more/lib_guide.htm, and
> >>> perhaps
> >>> one or two other current pages.
> >>
> >> How will we decide which are requirements and which are guidelines?
> >
> >My two cents:
> >
> >By default make everything a guideline.
>
> That's an interesting approach. But there should be at least one
> exception: Anything which is already a requirement in
> http://www.boost.org/more/lib_guide.htm stays a requirement. There are
> only four coding requirements currently, all having to do with portability.
>
> It should be possible to promote a few or the guidelines to be requirements
> if they are non-controversial. For example, I'd like to see "ISO Standard
> C++" elevated to a requirement, although even for that we would want to add
> a caveat allowing non-standard extensions be used in alternate
> implementations.
>
> > Convert the entire document into
> >the guidelines document. Then as time allows, promote things to be
> >requirements. You and Beman can decide whether formal review is required
> >or not for your initial requirements documents with your best judgement
> >and depending on how many requirements you end up with and whether they
> >are things that were controversial in the guidelines review process.
> >
> >The requirements will presumably be a small set compared with the
> >extensive set of guidelines. We can always downgrade a requirement to a
> >guideline after the fact, if we decide it was a mistake.
> >
> >The issues are not the same as with code, where making a change after the
>
> >library is accepted can easily result in incompatibilities for people
> >upgrading to a new version of the Boost libraries.
>
> --Beman
>
>
> Info: http://www.boost.org Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>