|
|
Boost Testing : |
From: Robert Ramey (ramey_at_[hidden])
Date: 2007-05-10 18:57:03
Gennadiy Rozental wrote:
> "Robert Ramey" <ramey_at_[hidden]> wrote in message
>> Since the changes are checked into the HEAD as they always have
>> been, boost regression testing would not change in any way. It
>
> This is not good from two standpoints:
>
> 1. You are *forcing* other developers to test against your latest
> release, while they may prefer to continue to rely on baseline (last
> boost release) version. If any problems arise will you rollback your
> changes? How is going to fix the libraries that depends on you?
>
> 2. What If I want to test against some version in between your HEAD
> and baseline version?
I expect to do whatever boost decides developer's should do. Any
problems with that system will not be particular to me. What I plan
to do is test against the latest version on my own machine (in the
privacy of my own home) and make my recent changes available to
anyone who wants them. It doesn't effect boost in any way.
> How could you "just put it there" if library development is on a
> branch for example?
I'll put my changes anywhere boost want's me to put them.
> In some sense you will always be required to remember what your older
> version did. At least for support. But again. With independent library
> versioning you may do your own releases as frequent a you wish and it
> should help you to keep track of your incremental development.
I'm not against independent library versioning. If thats what boost
want's to do its fine with me. I'm not sure what "versioning" means
here. Regardless what boost does, i feel its beneficial for me to test
on my own machine
> I must say I understand you very well. My proposition is to adopt the
> same procedure for all the libraries.
If boost buy in to that fine with me. My decision accomplish the
same benefit with requiring that boost change anything. It also
will work if boost changes something in its procedure.
> And as a result speedup the
> whole boost release procedures. Many users in big corporations can't
> rely on "beta" releases. They require an "official" boost release
> before they can accept any changes.
If they want to wait for the next "official" release its fine. My procedure
won't effect the official release date/timetable in any way.
>> In the case where I depend on a feature which has been deprecated
>> or interface which has been changed - I'm still stuck as I am
>> now. This is a problem beyond my power to fix - I either have
>> to adjust to it (by waiting) or work around it (by reducing
>> dependence). Just as I have to now.
>
> No. With independent library versioning you may refer and test with
> older version of the component that did not make the changes. Until
> you have time/resources to move on to adopt the changes in a
> dependency.
I see this as being even more complicated than the current situation.
But anyway its totally beside my point that developers can make
their lives much easier by testing against the last release rather
than against the development tree.
>>> You can't enforce freezing of development of all the libraries you
>>> depend on.
>>
>> I agree, I have to decide which dependencies are worth maintaining.
>
> This is not necessarily have to be "either or" decision.
hmmm - well seems like EITHER I depend upon another library
OR I don't.
>> I don't thing a more elaborate versioning system is going to achieve
>> this.
>
> I hope I made it clear.
LOL - nope.
But I'm not really discussing where boost should go and/or what boost
should do. My real point is that from my standpoint I can address
most of the difficulties related to boost developement by changing
my practices in a way that doesn't conflict with current or expected
boost policies. That's all I'm saying.
Robert Ramey