[hibernate-dev] HV: Handling of deprecations

[Gunnar Morling]

Hi,

thanks for your feedback.

I think we might go for a combined approach. For everything not
related to method validation (that is, the api/spi split related
changes), I've now added deprecation markers and at the same time the
new types [1]. So clients could adapt to these changes based on 4.3
and we can remove the old stuff in HV 5. That is, we're using the
deprecation mechanism as intended.

This generally works pretty good, although it causes some name
changes, if for instance the return type of a method changes (there
can't be two methods with the same name but different return type).

For the method validation API I've added deprecation markers, so that
users are informed about the upcoming change. In HV 5 we still can
decide whether to keep the old API around or remove it instantly. As
you say, this should be documented in the Wiki or release notes as
well.

--Gunnar

[1] https://github.com/gunnarmorling/hibernate-validator/compare/master...HV-561


2012/4/2 Emmanuel Bernard <emmanuel at hibernate.org>:
> But we probably don't have the bandwidth for a "4.9".
>
> On 2 avr. 2012, at 11:54, Sanne Grinovero wrote:
>
>> I don't know if it's doable, but having an API "deprecated" (literally
>> or just as a wiki warning) without having no alternative, and remove
>> it in next version makes it very hard to proceed iteratively in an
>> upgrade migration.
>>
>> If you want to "start clean" in version 5, as a user (hypothetically
>> speaking) I would appreciate something like a 4.9 release which
>> includes the new and the old APIs, deprecating the old:
>> that would make it much easier to deal with.
>>
>> Cheers,
>> Sanne
>>
>> On 2 April 2012 10:29, Hardy Ferentschik <hardy at hibernate.org> wrote:
>>>
>>> On Apr 1, 2012, at 11:56 AM, Gunnar Morling wrote:
>>>
>>>> I'm not really sure which is the better option here. Given that method
>>>> validation is the biggest new feature of BV 1.1 and HV 5 will be the
>>>> first release to implement that new version of the spec, I think it
>>>> would be ok if that release breaks clients without a previous
>>>> deprecation period. On the other hand it might actually be not that
>>>> complex to keep the old and the new API in HV 5 and remove the old one
>>>> in 5.1.
>>>
>>> For me the main reason for HV-561 and adding deprecation messages was to give
>>> the users a heads up on what's to come in HV 5. It is of course not strictly in the sense
>>> of @deprecated to not provide an alternative at the same time.
>>>
>>> Maybe Emmanuel is right and we should just use the blog and wiki to take care of this.
>>>
>>> Regarding keeping old and new in HV 5 and removing the old version in 5.1 I vote -1.
>>> I really would like to see a clear cut in HV 5. Also most of the changes are really trivial
>>> package renames.
>>>
>>> Personally I think it is  ok to add the deprecation warnings even w/o an immediate
>>> replacement. In a certain sense HV 4.3 is anyways a transition release for people
>>> between HV 4.2 (which is the reference implementation of Bean Validation 1.0)
>>> and HV 5 (which will be the reference implementation for BV 1.1).
>>> If we decide against the warnings I think we should just rely on blog and wiki to make sure
>>> everything is documented and people have a clear way of migration.
>>>
>>> --Hardy
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev