|
Boost : |
Subject: Re: [boost] Breaking existing libraries
From: Joel de Guzman (joel_at_[hidden])
Date: 2008-12-02 21:36:54
Markus Werle wrote:
>
> Example:
> In case of spirit we have the following situation:
> spirit2x (nomen est omen) is a *completely*
> different library with a completely different
> interface written on a different base and a really
> inferior stability compared to spirit 1
> (Even though it is ultimate high quality code and
> I begin to like it).
> Now that I became aware of what it means for me that
> good old spirit gets dropped and reworked this way
> I wish its new name was boost::ghost or whatever and
> spirit left in the state of 1.34.1:
> It works, it is fine, it has - of course - some limitations.
> So what? The parsers I have written with spirit are
> those parts of my code I never had to touch again
> (except once, see below).
> Sometimes no change is good.
> Also because I know most of spirit-1 oddities by heart
> and can fiddle small parsers within minutes I do not want
> to switch to 2x now.
> I acknowledge the hard work done to keep spirit1 in
> the distro, but I still dislike the way it was solved,
What in particular do you dislike?
> because I'd prefer spirit-1 to be a first class citizen
> for at least 3 more years.
And it will be. We value backwards compatibility. That is
why we took pains to keep the 1.8 code in the distro. And
I think it will remeain there for years to come. It would
be cruel to expect, say Robert Ramey's Serialization, to
be ported in a short period of time.
>> Judicious breakage does not necessarily mean that
>> the library is "experimental" in any meaningful way.
>
> Yes and no.
> If you touch it you probably will break one thing or
> another (and agile as you are fix it in 5 minutes after
> bug report).
>
> IMHO this also is a communication issue.
> On this list several people (me included) have already
> proposed to introduce stability labels.
> E.g. spirit2x *should* be tagged highly experimental
> pre-alpha code *despite* Joel's programming skills until
> many many users confirm its correct behaviour in Real World code.
It was tagged 2 years ago as highly experimental pre-alpha. It is
now tagged as beta. When it finally gets released as final, hopefully
before BoostCon 09, it would have taken an ample 3 years to reach
that level of maturity. True enough, many people are using it now
in projects.
Look: http://www.boost.org/doc/libs/1_37_0/libs/spirit/classic/index.html
what do you see? That's still 1.8.x. There's no drastic change there.
Spirit 1.8.x is, and always will be, first class. Isn't the name
"classic spirit" testament to that fact?
> We have to separate the quality label of the library
> from the quality label of its authors. Maybe that helps.
>
>> Nobody really has a problem with the stability of shared_ptr, for
>> example, and yet look at its list of breaking changes over the years:
>>
>> http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/compatibility.htm
>
> Most of these were extensions, bugfixes or improvements,
> not interface or silent breakage, right?
>
> The counter example:
> I had hard times with the rather silent change in spirit concerning
> trailing whitespaces and enforcing end_p.
> (http://www.nabble.com/Re%3A-grammar-rules-problem-p15635719.html)
> I agree with the change decision, but the change could have been
> advertized in big red letters on the main web page.
> It took me several months to detect _and_ understand the rather
> subtle errors it generated and this prevented migration to a new version
> of boost for a long time.
>
> This is OK for me, since Joel saved me a lot of time, but yes,
> this *change* broke all my code at once - silently. Something
> I do not like at all.
I agree. That was !BAD! (in all caps). It's one of the moves that
I regret. If I was to turn back time, I'd do it differently.
People make mistakes. I am sorry for this lapse in judgement.
I assure you, it won't happen again.
Now it is in bold red:
spirit.sf.net
Regards,
-- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk