+1 for this approach.
On Apr 3, 2012, at 12:20 AM, Gunnar Morling wrote:
> 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 an
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
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
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
spe
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 br
For such drastic moves, Hibernate Search has used the migration page on the
wiki to alert people. Not ideal but it works.
Emmanuel
On 1 avr. 2012, at 11:56, Gunnar Morling wrote:
> Hi all,
>
> Hardy and I have been discussing approaches for deprecating certain
> features in Hibernate Validator
