Re: Deprecations

[Scott Eade <se...@backstagetech.com.au>]

Thomas Vandahl wrote:
> Scott Eade wrote:
>   
>> Candidates for deprecation in 2.3.3:
>>
>>    * ScheduleService - not going to be ported to Fulcrum, use Fulcrum
>>      Quartz instead
>>    * LocalizationService - use Fulcrum Localization instead - relevant
>>      classes have not been carried over to trunk/2.4 so it should have
>>      been deprecated already anyway
>>    * IntakeService - same situation as l10n service
>>    * MimeTypeService - ditto
>>    * A bunch of other services for which we have Fulcrum components do
>>      still actually exist in the trunk/2.4 - should we not deprecate
>>      these also now so that we can have a cleaner base to work on with 2.4?
>>     
> I'd not deprecate any services in the 2.3 branch, I expressed my
> concerns about the state of their Fulcrum counterparts already. At least
> their inter-dependencies need to be resolved. Localization and Intake
> rely on the Factory and Pool services and the Parser component, which in
> turn depends on the Upload service. If you want to use one of them, you
> need to replace all. I would not want to recommend this to the user as
> long as we haven't sorted that mess out.
>   
Nothing says that we have to remove something that is deprecated in the 
immediately following release, but then it is also not really good form 
to deprecate things before the replacements are available.

Using this criteria I would suggest that we proceed with deprecating the 
ScheduleService since it is pretty much stand alone and it has a 
reasonably serious issue relating to DST that is unlikely to be addressed.

For the other services, I agree with your reasoning - i.e. let's hold 
off until their replacements have been fully implemented in the desired 
fashion.

Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org