Oh, apologies for hijacking
/me going for more coffee! ;)
On 08/23/2011 09:24 AM, Hardy Ferentschik wrote:
> FYI, the version should automatically be set by the build process. The
> 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
> 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 :-)
> On Tue, 23 Aug 2011 15:09:22 +0200, Scott Marlow<smarlow(a)redhat.com>
>> 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).
>> 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.
>>> Ok, just micro version updates then.
>>> hibernate-dev mailing list
>> hibernate-dev mailing list
> hibernate-dev mailing list
hibernate-dev mailing list