You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wink.apache.org by Bryant Luk <br...@gmail.com> on 2009/10/03 03:35:56 UTC
Any thing internal to public want to change?
Is there anything internal vs. public now that should be changed?
Just going through the documentation and looking at the interfaces to
see if there's anything in particular that should be moved around in
case we want to support something better (i.e. the handlers config
improvement and the moving of MediaTypeMapper). I wish to maintain
compatibility with the release as much as possible but I'm guessing
now is the time to sweep through.
Configuration options, names of configuration parameters, default
options, changes in the methods/classes, ideas, etc. Would really
appreciate any discussion.
Re: Any thing internal to public want to change?
Posted by Mike Rheinheimer <ro...@apache.org>.
Thanks Dims,
That would be a good solution too, so long as we remember to do it.
Changelogs are always valuable. We just have to do it as part of the call
for a release, not just as a post-release changelog generator.
Does Apache define such requirements for project releases? Is there a
best-practices checklist for releases? If not, should we create something
like this in WINK?
mike
On Mon, Oct 5, 2009 at 11:32 AM, Davanum Srinivas <da...@gmail.com> wrote:
> or we could run jdiff (http://javadiff.sourceforge.net/) before every
> release to vet the changes as part of the release process
>
> thanks,
> dims
>
>
> On 10/05/2009 12:28 PM, Mike Rheinheimer wrote:
>
>> Brian,
>>
>> Apologies in advance for not exactly answering your question. I do want
>> to
>> throw this suggestion along with volunteering for the work.
>>
>> In the interest of maintaining API signatures across releases (with the
>> exception of additions, which would be acceptable), I'd like to propose
>> that
>> we write signature tests for all interfaces and classes where needed.
>> Yes,
>> I'm volunteering for this work. :) I envision simple compilation tests
>> where the junit test has a nested class that imply implements the
>> interface
>> under test or extends the class under test. Having seen first-hand the
>> churn that signature changes cause when it happened in Apache Axis2, I
>> think
>> this would be a valuable thing to have in WINK.
>>
>> mike
>>
>>
>> On Fri, Oct 2, 2009 at 8:35 PM, Bryant Luk<br...@gmail.com> wrote:
>>
>> Is there anything internal vs. public now that should be changed?
>>> Just going through the documentation and looking at the interfaces to
>>> see if there's anything in particular that should be moved around in
>>> case we want to support something better (i.e. the handlers config
>>> improvement and the moving of MediaTypeMapper). I wish to maintain
>>> compatibility with the release as much as possible but I'm guessing
>>> now is the time to sweep through.
>>>
>>> Configuration options, names of configuration parameters, default
>>> options, changes in the methods/classes, ideas, etc. Would really
>>> appreciate any discussion.
>>>
>>>
>>
Re: Any thing internal to public want to change?
Posted by Davanum Srinivas <da...@gmail.com>.
or we could run jdiff (http://javadiff.sourceforge.net/) before every release to vet the changes as part of the release
process
thanks,
dims
On 10/05/2009 12:28 PM, Mike Rheinheimer wrote:
> Brian,
>
> Apologies in advance for not exactly answering your question. I do want to
> throw this suggestion along with volunteering for the work.
>
> In the interest of maintaining API signatures across releases (with the
> exception of additions, which would be acceptable), I'd like to propose that
> we write signature tests for all interfaces and classes where needed. Yes,
> I'm volunteering for this work. :) I envision simple compilation tests
> where the junit test has a nested class that imply implements the interface
> under test or extends the class under test. Having seen first-hand the
> churn that signature changes cause when it happened in Apache Axis2, I think
> this would be a valuable thing to have in WINK.
>
> mike
>
>
> On Fri, Oct 2, 2009 at 8:35 PM, Bryant Luk<br...@gmail.com> wrote:
>
>> Is there anything internal vs. public now that should be changed?
>> Just going through the documentation and looking at the interfaces to
>> see if there's anything in particular that should be moved around in
>> case we want to support something better (i.e. the handlers config
>> improvement and the moving of MediaTypeMapper). I wish to maintain
>> compatibility with the release as much as possible but I'm guessing
>> now is the time to sweep through.
>>
>> Configuration options, names of configuration parameters, default
>> options, changes in the methods/classes, ideas, etc. Would really
>> appreciate any discussion.
>>
>
Re: Any thing internal to public want to change?
Posted by Mike Rheinheimer <ro...@apache.org>.
Brian,
Apologies in advance for not exactly answering your question. I do want to
throw this suggestion along with volunteering for the work.
In the interest of maintaining API signatures across releases (with the
exception of additions, which would be acceptable), I'd like to propose that
we write signature tests for all interfaces and classes where needed. Yes,
I'm volunteering for this work. :) I envision simple compilation tests
where the junit test has a nested class that imply implements the interface
under test or extends the class under test. Having seen first-hand the
churn that signature changes cause when it happened in Apache Axis2, I think
this would be a valuable thing to have in WINK.
mike
On Fri, Oct 2, 2009 at 8:35 PM, Bryant Luk <br...@gmail.com> wrote:
> Is there anything internal vs. public now that should be changed?
> Just going through the documentation and looking at the interfaces to
> see if there's anything in particular that should be moved around in
> case we want to support something better (i.e. the handlers config
> improvement and the moving of MediaTypeMapper). I wish to maintain
> compatibility with the release as much as possible but I'm guessing
> now is the time to sweep through.
>
> Configuration options, names of configuration parameters, default
> options, changes in the methods/classes, ideas, etc. Would really
> appreciate any discussion.
>