[hibernate-dev] HV: Handling of deprecations

[Emmanuel Bernard]

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