[hibernate-dev] 6.0 Alpha1 prep

[Steve Ebersole]

At this point I feel comfortable that everything is good to go for Alpha1.
I've done a few dry runs using just publish and it looks good.  I have not
yet tried the full set of release tasks.

I am having trouble getting the staging hibernate.org build to work[1].  So
I won't be able to publish the website updates.  I have not yet started
with the release announcement.  But its probably better to come back to
these tasks after and just do the release and finish up these tasks after.
Any objections?

Note that this also includes relocations for all published 6.0 artifacts
under their old org.hibernate group-id

[1] http://ci.hibernate.org/view/Website/job/staging.hibernate.org/808

On Wed, Dec 5, 2018 at 10:04 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Wed, Dec 5, 2018 at 4:47 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> On Wed, Dec 5, 2018 at 9:28 AM Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>>
>>> So it's a detail but it's pretty handy to have relocations for these
>>> artifacts in the case of our test case template as we can test various
>>> versions without changing anything.
>>>
>>> If it's not a nightmare, I would keep them.
>>>
>>
>> Define nightmare ;)
>>
>> As for "test case templates", that is code we write/control - so not
>> understanding that point.
>>
>
> When someone uses our test case template, I often check if the issue also
> applies to previous versions. Often helps to narrow down the issue.
>
> If artifacts are consistent across versions, it's easier.
>
> It's convenient, not required.
>
>
>> Last release was 2.10.6 of October 2018. So it's still alive. I know we
>>> have users still using it.
>>>
>>
>>> If JCache covers all the features we had before, we could remove it and
>>> see how people reacts to it. It would still be time to reinject it later if
>>> someone comes up with a very compelling use case.
>>>
>>> And be done with it, if not.
>>>
>>
>> Not sure what to tell you about a new release aside from saying that we
>> often continue to release very old versions of ORM even though we do not
>> support them. The existence of a release does not mean it is supported.  I
>> have been told by the Ehcache developers that version 2 has not been
>> supported for many years (and that was almost a year ago).  Interpret that
>> how you want I guess.
>>
>> As for users still using it, that is a documentation issue imo.  I had
>> discussed this with Vlad previously that we ought to prefer
>> hibernate-jcache + ehcache 3 in the documentation, but it looks like that
>> has not happened.  Vlad?
>>
>
> Let's agree to agree on this one and remove it :).
>
>
>>
>>
>>>    - `hibernate-infinispan` - support for using Infinispan as a Hibernate
>>>
>>>
>>>>    L2C has been moved to the Infinispan project. Again, IMO this module
>>>> should
>>>>    go away.  Thoughts?
>>>>
>>>
>>> No opinion here.
>>>
>>
>> I am curious.  Why is this different to you compared to
>> hibernate-ehcache.  To me it is the same exact situation.
>>
>
>  It's mostly the "If JCache covers all the features we had before" I
> mentioned above that makes the difference. For Infinispan, we decided
> JCache was good enough. As for Ehcache, I'm wondering it all the features
> are exposed.
>
> The other thing is that I don't really know when the Infinispan code has
> been moved so I don't know if it's too early to remove it without
> relocation or not.
>
> So, no opinion :).
>
> --
> Guillaume
>