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 <ha...@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
