Hi,
FYI, the version should automatically be set by the build process. The
actual
java file contains the token "[WORKING]" which gets replaces by the
version specified
in the build file.
The magic which makes this happen is the InjectionPlugin (a gradle plugin)
which lives
in the buildSrc directory of the checkout. It used javassist to do the
token replacement
afaik.
Why the plugin execution failed during one particular release I don't
know. Which version
has this wrong version number?
BTW, initially we were talking about a Hibernate Search release :-)
--Hardy
On Tue, 23 Aug 2011 15:09:22 +0200, Scott Marlow <smarlow(a)redhat.com>
wrote:
I don't know how to do a Hibernate release but it seems like
some
releases don't have the org.hibernate.Version set (default of
"[WORKING]" is occasionally used).
It would be nice if this was set for any further releases (AS7 is trying
to use this to determine the difference between a 3.x or
4.x/laterMajor.x persistence provider class).
Thanks,
Scott
On 08/23/2011 05:11 AM, Sanne Grinovero wrote:
> 2011/8/23 Emmanuel Bernard<emmanuel(a)hibernate.org>:
>> Sure, you can trigger the release. I agree with your suggestions on
>> issue resolution except that I would not bump major (nor minor)
>> version numbers for the dependencies. Only micro.
>> For example, Infinispan 5 has broken compatibility on us several times
>> during the CR cycle. I would not dare to ask users to switch on a
>> maintenance release.
>>
>> Emmanuel
>
> Ok, just micro version updates then.
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev