|
|
Boost Testing : |
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-07 05:02:21
"Robert Ramey" <ramey_at_[hidden]> wrote in message
news:f1mdto$pif$1_at_sea.gmane.org...
>>>>> This doesn't address neither testing against new version of your
>>>>> library by developers of other libraries
>
> Developers can test which every they want. Regression testers
> can test whatever they want. I presume they would
> want to continue testing the HEAD. This doesn't help me
> much but if some finds it useful to some purpose, it's fine
> by me.
Developers quite possibly want to run tests against your new version not
locally, but using power of regression testing facility. Who is going to
install patches on regression tester sites?
>>> I am not sure how your reply relates to my comment. What I meant is:
>>> How can YOU test that your library works with the next version of
>>> let's say Boost.Test I am planning to include into next release.
>
> Ahhh - now that is the question. This can only fail if the next version
> of Boost.Test has a different interface than the previous version. If
Not necessarily. Boost.Test may not be the best example. But let's say you
want to employ new feature that implemented in next version of Boost.Test,
but is not yet part of Boost release?
> if the interface changes then a test failure would be an error in
> boost test which is beyond my scope, expertise and authority to
> address. So there is no point in my testing for it. If the
Another possibility is that next version of library finally remove some
deprecated interfaces and you aren't aware of this until you start testing
against new version.
> author of Boost Test wants to use the serialization library
> to test his new version - of course he's free to do so.
>
> If a library that I depend upon changes its interface and/or support
> too frequently, I'll have to decide on case by case basis
> whether using the library is more trouble than it's worth.
More complicated your library is, more dependencies it has. And more chances
that once in a while at least one of them is going to cause you some trouble
with new/updated/deprecated interfaces. Backward comparitibilty has it's
limits. At some point developer may be faced with a choice of breaking it or
missing some good opportunities.
> In any case, It seems current regression testing isn't going
> to change much in the near future so I would expect these
> kinds of errors will continue to be caught by the current system.
What kind of errors? Change in a dependency is not necessarily an error.
Though I may be. And then you are stuck until it's fixed.
>>>> I think boost as a concept has to change from tightly
>>>> coupled group of "standard" libraries to a loosely
>>>> coupled group of "interoperable" libraries. At its core
>>>> I think this is the issue. Good news is that its not something
>>>> that we have to agree upon. Its happening now as it
>>>> must as boost get beyond the scale where it can be
>>>> digested as a whole.
>>>
>>> This comment I completely agree with. I just propose how add some
>>> formalization to this process.
>
> Hmm - my "formalization" is to discourage libraries from
> changing their interface and/or support very often.
You can't enforce freezing of development of all the libraries you depend
on. Eventually it's always choice of either totally controlled "in-house
implementation" or dealing with occasional change. Also "often" is very
subjective term. For some people once in a few years is too often. Others
are OK with monthly releases. Advantage of independent versioning system is
that it should allow you to develop library in your own pace and don't have
to keep up with every release of component you depend on (with some
limitations).
Gennadiy