Just a quick update on my progress. I pretty much have
Session/EntityManager and SessionFactory/EntiytManagerFactory sorted out as
well as bootstrapping.
I am currently working through the different Query hierarchies.
Looking at what is left, I hope to be done with all of this by Thursday
On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
On 8 April 2016 at 15:04, Scott Marlow <smarlow(a)redhat.com>
wrote:
> I'm curious if Search/OGM master branches would likely align with 5.2?
> Or some other branch?
Good question, time for an update on these.
We'll certainly have a version of Search compatible, at some point.
Not sure though about which version that shall be as we want to be
feature complete with our Elasticsearch work, and that will take a
couple more months at least so we'll see a bit longer than usual gap
between stable releases.
Generally speaking we need at least a minor release for OGM or Search
to happen to upgrade the minor of ORM.
Since we didn't release yet, Search is still building with ORM 5.0.x
as a target.. we can then decide if we should skip ORM 5.1 and jump to
5.2 when we'll be closer to the 5.6.0.Final release (of Search). As
far as I know only some test helpers broke though, so while I couldn't
test it all on both versions 5.0 and 5.1 of ORM, I think that they are
compatible at runtime and we also expect to be compatible with ORM
5.2.
With OGM we're now in candidate release phase for a ORM 5.0 compatible
version so not really thinking to bump it to ORM 5.1 yet.
OGM tends to release less frequently, so in this case it is possible
that we might want to skip ORM 5.1 and go on 5.2 already to catch up,
but we can work on aiming a specific version if and when need arises.
If you need any of these aligned let us know?
Thanks,
Sanne
>
> On 04/07/2016 11:34 AM, Steve Ebersole wrote:
>> As a follow up to this...
>>
>> Sanne had a great suggestion on HipChat. What about turning all this
work
>> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would
be
>> 5.2 would include:
>>
>> 1. Move to Java 8
>> 2. Consolidation of hibernate-entitymanager into hibernate-core
>> 3. Deprecations, lots of deprecations :)
>>
>>
>> The idea is that then we could start 6.0 off "clean" by removing all
the
>> deprecations and layering in SQM work.
>>
>>
>>
>> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Until the merge is done, I'll take a break integrating the PRs that are
>>> also relevant to the master branch.
>>>
>>> Vlad
>>>
>>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <steve(a)hibernate.org>
>>> wrote:
>>>
>>>> I agree that would be best. If everyone agrees to stop pushing to
master
>>>> for the time being to allow me to finish this consolidation then I
can not
>>>> rush it as much
>>>>
>>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford
<crancran(a)gmail.com>
wrote:
>>>>
>>>>> I have to concur with Sanne, a hold on master pushes until this
merge of
>>>>> artifacts is complete makes the most sense from an all around
logistics
>>>>> perspective.
>>>>>
>>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero
<sanne(a)hibernate.org
>
>>>>> wrote:
>>>>>
>>>>>> Sounds reasonable. Do you think it will be unstable, i.e. should
we
>>>>>> temporarily disable complaint emails from Jenkins, or even the
full
>>>>>> build tasks?
>>>>>>
>>>>>> Also, this implies that any future backport becomes similarly
harder,
>>>>>> so you could also simply ask others to hold pushing on master,
then
>>>>>> have people forward-port when it's done.. it's the same
really but
>>>>>> that's why I mention it: as the complexity is
interchangeable it's a
>>>>>> fair request, with the difference you have:
>>>>>> - others help you port the other patches forward rather than
doing it
>>>>> all
>>>>>> alone
>>>>>> - the authors of the original patch doing it, that should make
it
a
>>>> bit
>>>>>> simpler
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6 April 2016 at 17:15, Steve Ebersole
<steve(a)hibernate.org>
wrote:
>>>>>>> Obviously consolidating hibernate-entitymanager into
hibernate-core
>>>> is
>>>>> a
>>>>>>> fairly big effort. And I am getting concerned about the
continuing
>>>>>> pushes
>>>>>>> to master in the meantime, many of which I know touch on
code I
have
>>>>>>> changed. My concern is obviously getting done all this
refactoring
>>>>> work
>>>>>>> and then having to sift through all of the changes that have
been
>>>>> pushed
>>>>>> in
>>>>>>> the interim and attempting to work out the proper
integration
>>>> strategy.
>>>>>>>
>>>>>>> Long story short... I am contemplating pushing to master
sooner
>>>> rather
>>>>>> than
>>>>>>> later even though my refactoring may not be completely
finished,
>>>>>> especially
>>>>>>> as we get towards the end of the week.
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>> _______________________________________________
>> 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
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev