You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/08/21 10:11:32 UTC
What does deprecated mean? - was: Re: Rename Node2/node2 to Node/node in trunk
On Thu, Aug 21, 2008 at 8:52 AM, haleh mahbod <hm...@gmail.com> wrote:
> Doesn't deprecation mean the code will be there for a while and therefore
> the new code will not break existing user code?
>
> How long will deprecated code stay around in Tuscany? It would be good to
> establish a guideline so users can plan to move to the new code.
>
> Can there be a log of deprecated APIs under documentation page or download
> page? This will help users to better plan for moving code to the new
> APIs/SPIs.
>
>
>
snip...
How about...
deprecated = the feature will remain in the code base for at least the next
2 releases at the 1.X level. During this time it won't be maintained and
users are encouraged to move away from it. After this time it is a candidate
for removal.
Thoughts?
Simon
Re: What does deprecated mean? - was: Re: Rename Node2/node2 to Node/node in trunk
Posted by ant elder <an...@apache.org>.
On Thu, Aug 21, 2008 at 10:44 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Thu, Aug 21, 2008 at 9:42 AM, ant elder <an...@gmail.com> wrote:
>
>>
>>
>> On Thu, Aug 21, 2008 at 9:11 AM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Thu, Aug 21, 2008 at 8:52 AM, haleh mahbod <hm...@gmail.com> wrote:
>>>
>>>> Doesn't deprecation mean the code will be there for a while and
>>>> therefore the new code will not break existing user code?
>>>>
>>>> How long will deprecated code stay around in Tuscany? It would be good
>>>> to establish a guideline so users can plan to move to the new code.
>>>>
>>>> Can there be a log of deprecated APIs under documentation page or
>>>> download page? This will help users to better plan for moving code to the
>>>> new APIs/SPIs.
>>>>
>>>
>>>
>>>>
>>>>
>>>
>>> snip...
>>>
>>> How about...
>>>
>>> deprecated = the feature will remain in the code base for at least the
>>> next 2 releases at the 1.X level. During this time it won't be maintained
>>> and users are encouraged to move away from it. After this time it is a
>>> candidate for removal.
>>>
>>> Thoughts?
>>>
>>> Simon
>>>
>>>
>>>
>> I think its likely to depend on the circumstances and could be different
>> for different types of changes. Its possible it could be fine in some
>> circumstances to remove a deprecated feature after just one release, for
>> some of the less important functions it may even be reasonable to remove
>> function without deprecation and just document the change in the release
>> notes. It is also to some degree time dependent as well as release dependent
>> and if we get several releases out over few months it could be better to not
>> remove a deprecated feature just because the set number of releases has
>> past. What i think is important is to consider the impact to users of
>> changes, so when it does seem like there could be significant user impact
>> then be more conservative, and vice versa.
>>
>
> I agree that it's a matter of circumstance but we should set some
> expectation. Having a variable approach will be hard to follow. I don't
> really object to keeping deprecated interfaces in the code base longer than
> we expected to keep them. Removing interfaces or changing the semantics with
> little warning will, I think, cause problems though.
>
>
>>
>>
>> As it could be hard to come up with a firm policy or guideline how about
>> saying changes that seem like they might impact backward compatibility
>> require at least lazy consensus, so post to the ML and wait at least 72
>> hours before making the change?
>>
>
> So this is a different but very good question. How do we judge whether a
> change is likely to affect backward compatibility? We have to look for red
> flags such as; does the change require changes to unit tests, itests or
> samples?. Given that we have some warning that a change is planned we can
> decide the best approach re. deprecation and migration.
>
>
>
Another aspect to this is what is considered the official backward
compatible set of features? We don't really have a clearly document set of
APIs/SPIs or list of stable modules, and we have experimental work that goes
on in trunk which sometimes does get into releases but is considered alpha
code to get community feedback. Should we try to come up with this doc?
One thing we could do is create an SCA community test suite like we have for
SDO, perhaps seeded from the existing itests and vtests but out of the
java/sca SVN tree so its hard to update without thinking. It could also do
things like include a copy of some of the extensions code to test the SPI
backward compatability, and have http unit type testing to test things like
web integration which doesn't normally get tested unless we manually run the
samples. Running that suite on each significant change or release we do
should help hightlight any backward compatibility issues.
...ant
Re: What does deprecated mean? - was: Re: Rename Node2/node2 to Node/node in trunk
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Aug 21, 2008 at 9:42 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Thu, Aug 21, 2008 at 9:11 AM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Thu, Aug 21, 2008 at 8:52 AM, haleh mahbod <hm...@gmail.com> wrote:
>>
>>> Doesn't deprecation mean the code will be there for a while and therefore
>>> the new code will not break existing user code?
>>>
>>> How long will deprecated code stay around in Tuscany? It would be good to
>>> establish a guideline so users can plan to move to the new code.
>>>
>>> Can there be a log of deprecated APIs under documentation page or
>>> download page? This will help users to better plan for moving code to the
>>> new APIs/SPIs.
>>>
>>
>>
>>>
>>>
>>
>> snip...
>>
>> How about...
>>
>> deprecated = the feature will remain in the code base for at least the
>> next 2 releases at the 1.X level. During this time it won't be maintained
>> and users are encouraged to move away from it. After this time it is a
>> candidate for removal.
>>
>> Thoughts?
>>
>> Simon
>>
>>
>>
> I think its likely to depend on the circumstances and could be different
> for different types of changes. Its possible it could be fine in some
> circumstances to remove a deprecated feature after just one release, for
> some of the less important functions it may even be reasonable to remove
> function without deprecation and just document the change in the release
> notes. It is also to some degree time dependent as well as release dependent
> and if we get several releases out over few months it could be better to not
> remove a deprecated feature just because the set number of releases has
> past. What i think is important is to consider the impact to users of
> changes, so when it does seem like there could be significant user impact
> then be more conservative, and vice versa.
>
I agree that it's a matter of circumstance but we should set some
expectation. Having a variable approach will be hard to follow. I don't
really object to keeping deprecated interfaces in the code base longer than
we expected to keep them. Removing interfaces or changing the semantics with
little warning will, I think, cause problems though.
>
>
> As it could be hard to come up with a firm policy or guideline how about
> saying changes that seem like they might impact backward compatibility
> require at least lazy consensus, so post to the ML and wait at least 72
> hours before making the change?
>
So this is a different but very good question. How do we judge whether a
change is likely to affect backward compatibility? We have to look for red
flags such as; does the change require changes to unit tests, itests or
samples?. Given that we have some warning that a change is planned we can
decide the best approach re. deprecation and migration.
>
> ..ant
>
>
Re: What does deprecated mean? - was: Re: Rename Node2/node2 to Node/node in trunk
Posted by ant elder <an...@gmail.com>.
On Thu, Aug 21, 2008 at 9:11 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Thu, Aug 21, 2008 at 8:52 AM, haleh mahbod <hm...@gmail.com> wrote:
>
>> Doesn't deprecation mean the code will be there for a while and therefore
>> the new code will not break existing user code?
>>
>> How long will deprecated code stay around in Tuscany? It would be good to
>> establish a guideline so users can plan to move to the new code.
>>
>> Can there be a log of deprecated APIs under documentation page or download
>> page? This will help users to better plan for moving code to the new
>> APIs/SPIs.
>>
>
>
>>
>>
>
> snip...
>
> How about...
>
> deprecated = the feature will remain in the code base for at least the next
> 2 releases at the 1.X level. During this time it won't be maintained and
> users are encouraged to move away from it. After this time it is a candidate
> for removal.
>
> Thoughts?
>
> Simon
>
>
>
I think its likely to depend on the circumstances and could be different for
different types of changes. Its possible it could be fine in some
circumstances to remove a deprecated feature after just one release, for
some of the less important functions it may even be reasonable to remove
function without deprecation and just document the change in the release
notes. It is also to some degree time dependent as well as release dependent
and if we get several releases out over few months it could be better to not
remove a deprecated feature just because the set number of releases has
past. What i think is important is to consider the impact to users of
changes, so when it does seem like there could be significant user impact
then be more conservative, and vice versa.
As it could be hard to come up with a firm policy or guideline how about
saying changes that seem like they might impact backward compatibility
require at least lazy consensus, so post to the ML and wait at least 72
hours before making the change?
..ant
Re: What does deprecated mean? - was: Re: Rename Node2/node2 to Node/node in trunk
Posted by ant elder <an...@gmail.com>.
On Thu, Aug 21, 2008 at 9:11 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Thu, Aug 21, 2008 at 8:52 AM, haleh mahbod <hm...@gmail.com> wrote:
>
>> Doesn't deprecation mean the code will be there for a while and therefore
>> the new code will not break existing user code?
>>
>> How long will deprecated code stay around in Tuscany? It would be good to
>> establish a guideline so users can plan to move to the new code.
>>
>> Can there be a log of deprecated APIs under documentation page or download
>> page? This will help users to better plan for moving code to the new
>> APIs/SPIs.
>>
>
>
>>
>>
>
> snip...
>
> How about...
>
> deprecated = the feature will remain in the code base for at least the next
> 2 releases at the 1.X level. During this time it won't be maintained and
> users are encouraged to move away from it. After this time it is a candidate
> for removal.
>
> Thoughts?
>
> Simon
>
>
>
I think its likely to depend on the circumstances and could be different for
different types of changes. Its possible it could be fine in some
circumstances to remove a deprecated feature after just one release, for
some of the less important functions it may even be reasonable to remove
function without deprecation and just document the change in the release
notes. It is also to some degree time dependent as well as release dependent
and if we get several releases out over few months it could be better to not
remove a deprecated feature just because the set number of releases has
past. What i think is important is to consider the impact to users of
changes, so when it does seem like there could be significant user impact
then be more conservative, and vice versa.
As it could be hard to come up with a firm policy or guideline how about
saying changes that seem like they might impact backward compatibility
require at least lazy consensus, so post to the ML and wait at least 72
hours before making the change?
..ant