On Mon, 17 Feb 2020 at 14:20, Steve Ebersole wrote:
>
> I tend to agree with Gail here. Sure Sanne I understand your view there, but
> realistically:
> 1) which other ORM jars do you see printing its version?
None, but I'm wondering if we wanted to improve on that.
> 2) when are you expecting
I tend to agree with Gail here. Sure Sanne I understand your view there,
but realistically:
1) which other ORM jars do you see printing its version?
2) when are you expecting that ORM jar versions can be mixed amongst the
different modules?
On Thu, Feb 13, 2020 at 10:42 AM Sanne Grinovero
wrote:
Thanks all, I'll make the changes then:
- https://hibernate.atlassian.net/browse/HHH-13863
Gail, answered to you below - sorry it took so long.
On Fri, 7 Feb 2020 at 18:24, Gail Badner wrote:
>
> +1 to changing it.
>
> The name was changed from "core" to "ORM" some years back. Can "core" just b
+1 to changing it.
The name was changed from "core" to "ORM" some years back. Can "core" just
be dropped now?
On Fri, Feb 7, 2020 at 6:20 AM Yoann Rodiere wrote:
> +1
>
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
>
>
> On Fri, 7 Feb 2020 at 14:58, Sanne Grinovero wrote:
>
> > It's
+1
Yoann Rodière
Hibernate Team
yo...@hibernate.org
On Fri, 7 Feb 2020 at 14:58, Sanne Grinovero wrote:
> It's minor cosmetics, but I'd like to change the format of the message
> we log on boot.
>
> Currently we have:
> INFO [org.hib.Version] HHH000412: Hibernate Core {5.4.11-SNAPSHOT}
>
Sorry, I referenced the incorrect release announcement in my previous
email. It should have been:
http://in.relation.to/2019/04/22/hibernate-orm-5310-final-out/
On Mon, Apr 22, 2019 at 2:27 PM Gail Badner wrote:
> http://in.relation.to/2019/02/19/hibernate-orm-538-final-out/
>
__
Awesome, congratulations all!
On Thu, 15 Nov 2018 at 15:30, Guillaume Smet
wrote:
>
> Hi,
>
> We just released Hibernate ORM 5.4.0.CR1, the first candidate release of
> 5.4.0.
>
> 5.4 is the direct continuation of 5.3 and we will encourage everyone to
> upgrade to it to benefit from the latest fix
ORM 5.1.16 is now available on Central.
On Wed, Sep 12, 2018 at 9:01 AM Yoann Rodiere wrote:
> Same goes with the Hibernate Search artifacts I published about 36 hours
> ago.
>
> I updated the JBoss Nexus ticket.
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
>
> On Tue, 11 Sep
Same goes with the Hibernate Search artifacts I published about 36 hours
ago.
I updated the JBoss Nexus ticket.
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On Tue, 11 Sep 2018 at 21:59, Gail Badner wrote:
> Strange. Any idea if this has anything to do with the maintenance done on
>
Strange. Any idea if this has anything to do with the maintenance done on
Nexus?
On Mon, Sep 10, 2018 at 6:15 AM, Yoann Rodiere wrote:
> Thanks Guillaume, at least it's on someone else's plate now :)
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
>
> On Mon, 10 Sep 2018 at 14:4
Thanks Guillaume, at least it's on someone else's plate now :)
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On Mon, 10 Sep 2018 at 14:43, Guillaume Smet
wrote:
> On Mon, Sep 10, 2018 at 11:58 AM Yoann Rodiere
> wrote:
>
>> I'll stick to 5.1.15 for now in Hibernate Search, but maybe
On Mon, Sep 10, 2018 at 11:58 AM Yoann Rodiere wrote:
> I'll stick to 5.1.15 for now in Hibernate Search, but maybe we should
> report this issue to someone? Guillaume, maybe the same people you reported
> your Validator issue to?
>
I reported it in the issue I opened for HV a while ago.
Don't
On Mon, Sep 10, 2018 at 2:34 PM Steve Ebersole wrote:
> Often when releasing to BinTray I have to manually trigger the sync to
> Central. Not sure why and it's never been a big enough issue to
> investigate - I just know to check as part of my release process.
>
I think 5.1 is still using Nexus
Often when releasing to BinTray I have to manually trigger the sync to
Central. Not sure why and it's never been a big enough issue to
investigate - I just know to check as part of my release process.
It would ultimately be great to figure out why the auto sync does not work.
On Mon, Sep 10, 20
I'll give it a try.
Thanks!
On Fri, Jun 8, 2018 at 1:42 PM, Steve Ebersole wrote:
> Have you tried https://plugins.gradle.org/plugin/me.champeau.gradle.
> japicmp ?
>
> On Fri, Jun 8, 2018 at 3:29 PM Gail Badner wrote:
>
>> I re-ran japi-compliance-checker on Wednesday (6/6/18) comparing binar
Have you tried https://plugins.gradle.org/plugin/me.champeau.gradle.japicmp
?
On Fri, Jun 8, 2018 at 3:29 PM Gail Badner wrote:
> I re-ran japi-compliance-checker on Wednesday (6/6/18) comparing binary
> compatibility of 5.1.15-SNAPSHOT vs 5.2.3-SNAPSHOT.
>
> I've summarized the results at [1].
+1.
Unless there will be some serious issues that call for a 5.2.19 release, we
should focus on 5.3.
Vlad
On Wed, Jun 6, 2018 at 3:45 PM, Steve Ebersole wrote:
> +1 to stopping 5.2 releases.
>
> On Wed, Jun 6, 2018 at 7:40 AM Guillaume Smet
> wrote:
>
> > On Tue, Jun 5, 2018 at 10:33 PM Gail
I'm fine postponing the release for another week or 2 if that helps,
Christian.
On 06/06/2018 08:26 AM, Guillaume Smet wrote:
> On Tue, Jun 5, 2018 at 10:33 PM Gail Badner wrote:
>
>> Chris mentioned that he is planning to release 5.2.18 on Thursday.
>>
> It would be nice if we could get
> https
+1 to stopping 5.2 releases.
On Wed, Jun 6, 2018 at 7:40 AM Guillaume Smet
wrote:
> On Tue, Jun 5, 2018 at 10:33 PM Gail Badner wrote:
>
> > Chris mentioned that he is planning to release 5.2.18 on Thursday.
> >
>
> It would be nice if we could get
> https://hibernate.atlassian.net/browse/HHH-1
On Tue, Jun 5, 2018 at 10:33 PM Gail Badner wrote:
> Chris mentioned that he is planning to release 5.2.18 on Thursday.
>
It would be nice if we could get
https://hibernate.atlassian.net/browse/HHH-12645 fixed before releasing
5.2.18, considering it's a regression introduced after 5.2.13. If we
Thanks. I will have to look if we have some outdated docs pointing to the
old artefact.
On Tue, 29 May 2018, 18:21 Chris Cranford, wrote:
> I believe we renamed it to `hibernate-orm-jbossmodules` in 5.3.0.CR2 as I
> see that with 5.3.1.Final too.
>
> On 05/29/2018 10:59 AM, Vlad Mihalcea wrote:
I believe we renamed it to `hibernate-orm-jbossmodules` in 5.3.0.CR2 as
I see that with 5.3.1.Final too.
On 05/29/2018 10:59 AM, Vlad Mihalcea wrote:
> I checked this forum question:
>
> https://discourse.hibernate.org/t/org-hibernate-hibernate-orm-modules-no-longer-published/861/2
>
> And, indeed
Related with the TypeConfiguration and BootstrapContext work, I have just
made a PR targeting your last comments, but I need to know if the work done
it's fine and especially if it is enough to be considered done and then
integrated.
On 22 March 2018 at 14:15, Steve Ebersole wrote:
> Still waiti
Still waiting for feedback on the PR or Jira. I will integrate upstream
today if I don't hear replies needing changes
But regardless, this is not the only change CR2 is waiting on as I
mentioned before
On Thu, Mar 22, 2018, 8:54 AM Sanne Grinovero wrote:
> Could you help us understand. None o
Could you help us understand. None of the SPI changes have been merged
in master yet?
On 22 March 2018 at 13:39, Steve Ebersole wrote:
> Then you'll have to wait. Seems like snapshot is better than waiting but of
> course your opinion seems just waiting is better...
>
> On Thu, Mar 22, 2018 at 8
Then you'll have to wait. Seems like snapshot is better than waiting but
of course your opinion seems just waiting is better...
On Thu, Mar 22, 2018 at 8:34 AM Sanne Grinovero wrote:
>
> No, snapshots are confusing when you need multiple people to collaborate
> on a POC.
>
> It's not clear if a
No, snapshots are confusing when you need multiple people to collaborate on
a POC.
It's not clear if a patch will work the same to others and it's unpractical
to match to a specific source commit.
Why would we ever publish CRs if SNAPSHOTS are the same.
On Thu, 22 Mar 2018, 13:17 Steve Ebersole,
Like a snapshot?
On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero wrote:
> On 22 March 2018 at 12:18, Steve Ebersole wrote:
> > There is already a branch that contains these changes that they can work
> > with... no need to wait for a CR. I still want to let Andrea finish the
> > work on TypeConf
On 22 March 2018 at 12:18, Steve Ebersole wrote:
> There is already a branch that contains these changes that they can work
> with... no need to wait for a CR. I still want to let Andrea finish the
> work on TypeConfiguration and BootstrapContext before we cut CR2.
It would help to have a tagged
There is already a branch that contains these changes that they can work
with... no need to wait for a CR. I still want to let Andrea finish the
work on TypeConfiguration and BootstrapContext before we cut CR2.
On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero wrote:
> Steve, all,
>
> would it be
If it's a matter of reviewing code, I'm happy to help. In that case, my
name should be added as a reviewer.
BTW, I forget to check all the various ways I can be contacted, so a
personal email or hipchat message. helps.
On Tue, Jan 30, 2018 at 5:52 AM, Sanne Grinovero
wrote:
> In some cases - ma
In some cases - maybe not these specifically - I know people ask your
review when it gets tricky, as you're the most thorough reviewer and
have deep knowledge of most areas :) Maybe that was the case, maybe
not. Good to clarify either way.
Thanks!
Sanne
On 30 January 2018 at 00:59, Gail Badner
I've seen at least one jira comment asking if I approve backporting to 5.2,
and I also remember seeing a PR that had "Requires Gail" label with a
comment suggesting bugfixes in older branches (including 5.2) must be
approved by me.
I just wanted to make this clear so that bugfixes that should be b
I don't think anyone mentioned expecting you to do this. In fact the
discussions I have had about this was that others would help with this
(after 5.2.13).
On Wed, Jan 24, 2018 at 5:20 PM Gail Badner wrote:
> People seem to be relying on me to backport to 5.2. From a product
> standpoint, ther
I don't know how applicable this is to the Hibernate project, but a
workflow I've seen is you do the fixes in the old maintenance-only branches
(say 5.1) and then merge or cherry-pick those changes into the
current-release branch. Of course if they've diverged too drastically in
very few commits, t
For what it's worth, +1 on this. At least back in the day, we'd
continue to backport bugfixes to the previous minor release, until a new
final minor release was deployed. That was the responsibility of
whoever was committing to master. Since the baselines were typically
"close enough", commi
After WildFly 11 and EAP 7.1.0.GA is released, or shortly thereafter, ORM
5.1 will no longer be publicly released, so it really is not worthwhile to
backport this to 5.1.
Sorry for asking, I didn't think it through before sending.
On Wed, Aug 30, 2017 at 9:26 AM, Steve Ebersole wrote:
> As I sa
As I said initially, I agree that 5.2 should be updated. We just need to
be clear about the ramifications.
On Wed, Aug 30, 2017 at 11:14 AM Sanne Grinovero
wrote:
> On 30 August 2017 at 16:53, Steve Ebersole wrote:
> >
> > On Wed, Aug 30, 2017 at 10:38 AM Sanne Grinovero
> > wrote:
> >>
> >>
On 30 August 2017 at 16:53, Steve Ebersole wrote:
>
> On Wed, Aug 30, 2017 at 10:38 AM Sanne Grinovero
> wrote:
>>
>> On 29 August 2017 at 20:28, Steve Ebersole wrote:
>> > Then I think we should update 5.2 as well, but that creates an
>> > interesting
>> > concern in that the published artifact
On Wed, Aug 30, 2017 at 10:38 AM Sanne Grinovero
wrote:
> On 29 August 2017 at 20:28, Steve Ebersole wrote:
> > Then I think we should update 5.2 as well, but that creates an
> interesting
> > concern in that the published artifact name would change if I understand
> > correctly because it would
On 29 August 2017 at 20:28, Steve Ebersole wrote:
> Then I think we should update 5.2 as well, but that creates an interesting
> concern in that the published artifact name would change if I understand
> correctly because it would change the artifact's classifier from
> `wildfly-10-dist` to `wildf
Then I think we should update 5.2 as well, but that creates an interesting
concern in that the published artifact name would change if I understand
correctly because it would change the artifact's classifier from
`wildfly-10-dist` to `wildfly-11-dist`. Things that refer to this artifact
as a depen
Hibernate ORM 5.1.x is in WF 11.
On Mon, Aug 28, 2017 at 4:20 PM, Steve Ebersole wrote:
> What version of Hibernate does WF 11 include?
>
> On Mon, Aug 28, 2017, 5:18 PM Gail Badner wrote:
>
>> This should be backported to 5.1 as well, shouldn't it?
>>
>> On Sun, Aug 27, 2017 at 2:27 PM, Steve
What version of Hibernate does WF 11 include?
On Mon, Aug 28, 2017, 5:18 PM Gail Badner wrote:
> This should be backported to 5.1 as well, shouldn't it?
>
> On Sun, Aug 27, 2017 at 2:27 PM, Steve Ebersole
> wrote:
>
>> +1
>>
>> Thanks Sanne!
>>
>> On Sun, Aug 27, 2017 at 4:06 PM Sanne Grinovero
This should be backported to 5.1 as well, shouldn't it?
On Sun, Aug 27, 2017 at 2:27 PM, Steve Ebersole wrote:
> +1
>
> Thanks Sanne!
>
> On Sun, Aug 27, 2017 at 4:06 PM Sanne Grinovero
> wrote:
>
> > Thanks Steve!
> > for reference JIRA and PR:
> > - https://hibernate.atlassian.net/browse/HHH
+1
Thanks Sanne!
On Sun, Aug 27, 2017 at 4:06 PM Sanne Grinovero wrote:
> Thanks Steve!
> for reference JIRA and PR:
> - https://hibernate.atlassian.net/browse/HHH-11950
> - https://github.com/hibernate/hibernate-orm/pull/1994
>
> I also just noticed that supporting only the latest is consist
Thanks Steve!
for reference JIRA and PR:
- https://hibernate.atlassian.net/browse/HHH-11950
- https://github.com/hibernate/hibernate-orm/pull/1994
I also just noticed that supporting only the latest is consistent with
the expectations we set in the documentation.
Thanks,
Sanne
On 27 August 20
I personally agree that we should only be maintaining a single slice of the
version matrix here... a given ORM version against the latest Wildfly
version.
On Sun, Aug 27, 2017, 7:31 AM Sanne Grinovero wrote:
> Hi all,
>
> WildFly 11 is coming: the version 11.0.0.CR1 was just released last week.
+1
On Mon, Jul 24, 2017 at 10:20 AM Vlad Mihalcea
wrote:
> Hi,
>
> Since it's more than one year since we switched to Asciidoc, I think we
> should remove the docbook folder.
>
> Does anyone has anything against it or thinks this is not a good idea?
>
> Vlad
> ___
Byteman needs to open a socket into the JVM to inject its magic: you
can't otherwise rewrite the bytecode of any class.
Since various tools we use, like Byteman, Arquillian, Infinispan,
WildFly, JGroups, and probably some others I'm forgetting require
network ports we normally run CI build jobs in
This error:
"unexpected exception opening server socket java.net.BindException: Address
already in use (Bind failed)"
I only got it when NVidia driver was stealing the Wildfly port, but that
was never for CriteriaLockingTest.
It's also curious why the Byteman agent tries to open a socket connec
https://hibernate.atlassian.net/browse/HHH-11444
On Tue, Jan 31, 2017 at 12:52 AM Christian Beikov <
christian.bei...@gmail.com> wrote:
> Sounds good to me. +1
>
> Am 30.01.2017 um 17:31 schrieb Steve Ebersole:
> > Relatedly, I have been thinking whether we want to rename the ORM
> artifacts
> >
Good points Gunnar. So then we'll plan to rename hibernate-core to
hibernate-orm and the others from hibernate-{module} to
hibernate-orm-{module}.
On Tue, Jan 31, 2017 at 2:09 AM Gunnar Morling wrote:
> Agreed, it'd be the right time if we wanted to change this.
>
> I vote for 1 in case we do
The underlying problem is still unfixed[1]. There is a work around we
could try.
[1] https://issues.gradle.org/browse/GRADLE-2966 ->
https://github.com/gradle/gradle/issues/1061
On Wed, Feb 1, 2017 at 11:43 AM Steve Ebersole wrote:
> Most likely it is the cycle between hibernate-core and
> hi
Most likely it is the cycle between hibernate-core and
hibernate-orm-modules. Let me research a bit...
On Tue, Jan 31, 2017 at 2:34 PM andrea boriero wrote:
> rebased my old PR and it stops working, the "publishing is not yet able to
> resolve a dependency on a project with multiple different
rebased my old PR and it stops working, the "publishing is not yet able to
resolve a dependency on a project with multiple different publications"
exception is back :(
I'm investigating to understand what change reintroduced this issue.
On 31 January 2017 at 09:57, andrea boriero wrote:
> after
after thinking a bit on +1 for Steve proposal
On 31 January 2017 at 08:09, Gunnar Morling wrote:
> Agreed, it'd be the right time if we wanted to change this.
>
> I vote for 1 in case we do it.
>
> In ORM it's enough for many use cases to just add that core module,
> hence I like the more concis
Agreed, it'd be the right time if we wanted to change this.
I vote for 1 in case we do it.
In ORM it's enough for many use cases to just add that core module,
hence I like the more concise "hibernate-orm" id (similar to
"hibernate-validator"). It's a bit different for OGM and HSEARCH where
one ne
Sounds good to me. +1
Am 30.01.2017 um 17:31 schrieb Steve Ebersole:
> Relatedly, I have been thinking whether we want to rename the ORM artifacts
> as well since this is the best time if we wanted to do that.
>
> So we know we will change the groupId to `org.hibernate.orm`.
>
> I was thinking we
Not have a strong opinion on the renaming.
On 30 Jan 2017 19:05, "andrea boriero" wrote:
I worked on the ORM relocation script probably a year ago, I'll have to go
back and refresh my memory. Tomorrow I'll give a look at it.
On 30 Jan 2017 16:44, "Steve Ebersole" wrote:
> Relatedly, I have be
I worked on the ORM relocation script probably a year ago, I'll have to go
back and refresh my memory. Tomorrow I'll give a look at it.
On 30 Jan 2017 16:44, "Steve Ebersole" wrote:
> Relatedly, I have been thinking whether we want to rename the ORM artifacts
> as well since this is the best tim
Hi Valerie! Just comment on the issue that you are giving it a try and
work on it in a branch on your fork of hibernate-orm repo. When you are
done, send us a pull request.
Thanks for your interest
On Thu, Jan 19, 2017, 9:57 AM Valerie Arena wrote:
> Hello,
>
> I would like to contribute to H
On 16 January 2017 at 18:49, Steve Ebersole wrote:
> I think we are all saying that we personally find it far more useful to have
> the sources (which have the Javadoc btw ;) available in the IDE compared to
> having just the Javadoc.
I definitely agree but it's not an exclusive either/or ;)
> I
I think we are all saying that we personally find it far more useful to
have the sources (which have the Javadoc btw ;) available in the IDE
compared to having just the Javadoc.
It's not a question of easy to generate/publish, it's a question of what is
useful. If someone finds it useful they can
I'm not sure if the agreement is in wanting to keep the status quo, or
if it's simply not worth our time to chase such things. In other
words: may I suggest to such users that we'd accept a pull request, or
you'd rather not waste bandwidth during releases?
Either way is fine by me, but I wonder if
I agree with Steve and Gunnar.
On 16 January 2017 at 15:41, Gunnar Morling wrote:
> +1 The source JARs are the important thing here.
>
> Just tried out the JavaDoc view in Eclipse for the first time as
> you're mentioning it. Can't say I find it overly useful nor that I've
> been missing it for
+1 The source JARs are the important thing here.
Just tried out the JavaDoc view in Eclipse for the first time as
you're mentioning it. Can't say I find it overly useful nor that I've
been missing it for all these years :)
2017-01-16 15:43 GMT+01:00 Steve Ebersole :
> I personally think that publ
I personally think that publishing Javadocs per artifact is silly so I do
not do it for ORM. Its a limiting view. We already publish an
"aggregated" Javadoc that (again imo) is far better. As you point out
Sanne, we do publish sources to repo which at the IDE level is MUCH better
On Mon, Jan 16
Hi,
It's an issue we have for several of our projects (ie also on NoORM
projects), namely those building the javadoc in an aggregated task at the
end of the build.
It bugged me a little at first but as Eclipse defaults to using source
anyway, I didn't care that much about this. It might be a good
N.P. It's fixed now on master.
I checked other branches but didn't seem to have this problem.
On 2 September 2016 at 13:16, Vlad Mihalcea wrote:
> Damn. I must have missed it when I reviewed the PR.
> Good thing that you caught it.
>
> Vlad
>
> On Fri, Sep 2, 2016 at 2:57 PM, andrea boriero wr
Damn. I must have missed it when I reviewed the PR.
Good thing that you caught it.
Vlad
On Fri, Sep 2, 2016 at 2:57 PM, andrea boriero wrote:
> yes I also believe it was a mistake
>
> On 2 September 2016 at 12:34, Sanne Grinovero wrote:
>
> > Sebastian Laskawiec pointed out that there is indee
yes I also believe it was a mistake
On 2 September 2016 at 12:34, Sanne Grinovero wrote:
> Sebastian Laskawiec pointed out that there is indeed a submodule,
> introduced by this commit:
>
> https://github.com/hibernate/hibernate-orm/commit/
> e75b017a4664d158e1197d19dca204273c4a2d66#diff-
> b827
Ah, looks like it came from a contribution and not noticed as it was
applied. Yes that is a mistake.
On Fri, Sep 2, 2016 at 6:34 AM Sanne Grinovero wrote:
> Sebastian Laskawiec pointed out that there is indeed a submodule,
> introduced by this commit:
>
>
> https://github.com/hibernate/hiberna
Sebastian Laskawiec pointed out that there is indeed a submodule,
introduced by this commit:
https://github.com/hibernate/hibernate-orm/commit/e75b017a4664d158e1197d19dca204273c4a2d66#diff-b82723dbef3c19115685625a04d6071dR1
I guess it's a mistake... I'll delete it soon, ping me if I shouldn't.
T
Nope
On Thu, Sep 1, 2016, 4:25 PM Sanne Grinovero wrote:
> Hi all,
> the Infinispan/Hibernate integration test - which is run by the
> Infinispan team and uses TeamCity instead of Jenkins - is failing with
> the below cryptic error.
>
> Did the ORM switch to using Git modules?
>
> Error collecti
I've been reviewing the differences in APIs/SPIs for 5.0 vs 5.1. They are
primarily changes in SPI (which is OK), but there are a couple of changes
that I need to investigate further to ensure they won't affect
applications. I don't see anything insurmountable at this point. If
necessary, I think w
5.0.10 and 5.1.1 needed to be delayed while we dealt with a critical bug,
HHH-10795. I am also working with John O'Hara to fix a performance
regression that was introduced into 5.0.10 and, presumably, would be in
5.1.1.
Another reason I've been holding off on releasing 5.1.1 was because of the
fai
ORM 5.1, has an improvement for how we interact with CDI, that I really
want to finish coding the WildFly side of, so I feel the *pain* of not
having this yet.
On 08/11/2016 02:04 PM, Gunnar Morling wrote:
> Hi Scott,
>
>> As part of bringing ORM 5.1.1+ into WF 10.1 or 11, we need to first
>> en
Hi Scott,
> As part of bringing ORM 5.1.1+ into WF 10.1 or 11, we need to first
> ensure that ORM 5.1.1 is completely *compatible* with ORM 5.0.x.
How does this ensuring look like? Is passing the WF test suite enough, or
are there further criteria? If identifying changes to the API is what you
ar
On 08/11/2016 10:45 AM, Sanne Grinovero wrote:
> On 11 August 2016 at 15:19, Scott Marlow wrote:
>>
>> On 08/11/2016 06:19 AM, Sanne Grinovero wrote:
>>>
>>> I've been watching this:
>>> - https://github.com/wildfly/wildfly/pull/8984
>>>
>>> And that's the reason I've been asking for a 5.1 rele
On 11 August 2016 at 15:19, Scott Marlow wrote:
>
> On 08/11/2016 06:19 AM, Sanne Grinovero wrote:
>>
>> I've been watching this:
>> - https://github.com/wildfly/wildfly/pull/8984
>>
>> And that's the reason I've been asking for a 5.1 release, as it has
>> been blocked by issues for long.
>>
>> I
On 08/11/2016 06:19 AM, Sanne Grinovero wrote:
> I've been watching this:
> - https://github.com/wildfly/wildfly/pull/8984
>
> And that's the reason I've been asking for a 5.1 release, as it has
> been blocked by issues for long.
>
> Indeed if this wasn't being tracked for 10.1 that's sad as we n
Hi Gunnar,
I'm not against ORM 5.1.1 being included in WildFly 10.1, but it is more
likely to be in WildFly 11, since WildFly 10.1 is likely to be released
before ORM 5.1.1.
Scott
On 08/11/2016 03:23 AM, Gunnar Morling wrote:
> Hi Scott, all,
>
> Are there any plans to upgrade ORM in the WF 10
I've been watching this:
- https://github.com/wildfly/wildfly/pull/8984
And that's the reason I've been asking for a 5.1 release, as it has
been blocked by issues for long.
Indeed if this wasn't being tracked for 10.1 that's sad as we need
WildFly releases with up to date versions of ORM to make
Ah, OK. I was confusing WildFly 10.1 with 11. I'm not sure about the
version for 10.1.
Scott?
On Thu, Aug 11, 2016 at 1:56 AM, Martin Simka wrote:
> Hi Gail,
>
> are you sure? I'm only aware of WFLY-6930 (Upgrade Hibernate to 5.0.10)
> and I'm not sure if it makes it to 10.1. Then there is WFLY
Hi Gail,
are you sure? I'm only aware of WFLY-6930 (Upgrade Hibernate to 5.0.10) and
I'm not sure if it makes it to 10.1. Then there is WFLY-6854 (Upgrade
Hibernate ORM to 5.1.x) which is targeted to WildFly 11.
https://issues.jboss.org/browse/WFLY-6930
https://issues.jboss.org/browse/WFLY-6854
Hi Gunnar,
10.1 will use ORM 5.1.
Regards,
Gail
On Thu, Aug 11, 2016 at 12:23 AM, Gunnar Morling
wrote:
> Hi Scott, all,
>
> Are there any plans to upgrade ORM in the WF 10.1 release?
>
> I somehow assumed that 10.1 would come with ORM 5.1, but it's still using
> 5.0.9. At least 5.0.10 would b
This one works as well:
https://github.com/hibernate/hibernate-ogm/blob/5.0.1.Final/changelog.txt
We could also add the changelog link in the download page for each
release: http://hibernate.org/orm/downloads/
On Fri, Jul 1, 2016 at 11:39 PM, Sanne Grinovero wrote:
> We have several options, the
We have several options, these alternatives work already:
-
https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HHH%20AND%20fixVersion%20%3D%205.2.1
- https://raw.githubusercontent.com/hibernate/hibernate-orm/5.2.1/changelog.txt
the second option is similar to Steve's proposal but point
Maybe we could create an easier to remember link to the changelog on
github, something like
http://orm.hibernate.org/changelog/5.2.1.Final
On Fri, Jul 1, 2016 at 9:46 PM, Steve Ebersole wrote:
> That is an ongoing argument with Atlassian. So yes, there is a way. It
> means disabling the GitHub
That is an ongoing argument with Atlassian. So yes, there is a way. It
means disabling the GitHub integration. I personally find the solution
worse than the problem. Also realize that it is always available via the
SCM'ed changelog file:
https://github.com/hibernate/hibernate-orm/blob/master/ch
People on Reddit complain that they cannot see the list of resolved issues
without being logged into JIRA:
https://www.reddit.com/r/java/comments/4qqo8p/hibernate_orm_521_has_been_released/
.
Can we make that change log visible without the need for an account?
Otherwise it's very hard for people t
Congrats, Andrea for the release.
Vlad
On Fri, Jul 1, 2016 at 11:19 AM, andrea boriero
wrote:
> i have just realized and sent a new message with the correct subject.
>
> Thanks
>
> On 1 July 2016 at 10:16, Sanne Grinovero wrote:
>
> > Hi Andrea,
> > the email subject mentions 5.0.9, the blog t
i have just realized and sent a new message with the correct subject.
Thanks
On 1 July 2016 at 10:16, Sanne Grinovero wrote:
> Hi Andrea,
> the email subject mentions 5.0.9, the blog talks about 5.2.1 .. did we
> release both?
>
> Thanks,
> Sanne
>
> On 1 July 2016 at 09:13, andrea boriero wro
Hi Andrea,
the email subject mentions 5.0.9, the blog talks about 5.2.1 .. did we
release both?
Thanks,
Sanne
On 1 July 2016 at 09:13, andrea boriero wrote:
> For details:
> http://in.relation.to/2016/06/30/hibernate-orm-521-final-release/
> ___
> hibe
That's it, thanks!
On Fri, Jun 24, 2016 at 11:13 AM Sanne Grinovero
wrote:
> On 24 June 2016 at 16:40, Steve Ebersole wrote:
> > I definitely want it run regularly (i.e. not "just before a release").
> I'd
> > be ok with it being nightly. That's why I asked in the first place.
> > Everyone who
On 24 June 2016 at 16:40, Steve Ebersole wrote:
> I definitely want it run regularly (i.e. not "just before a release"). I'd
> be ok with it being nightly. That's why I asked in the first place.
> Everyone who responded +1'd to it being on-each-push. I really don't care.
> I tend to agree it sh
I definitely want it run regularly (i.e. not "just before a release"). I'd
be ok with it being nightly. That's why I asked in the first place.
Everyone who responded +1'd to it being on-each-push. I really don't
care. I tend to agree it should be nightly, but I only get one vote :)
So the one
If check is so compute intensive, does it really have to be done on each
commit? When I've seen failures, it has been easy to figure out what is
wrong. Can the check job be done nightly, or on demand (e.g., before a
release)?
On Sat, Jun 18, 2016 at 11:20 AM, Steve Ebersole
wrote:
> http://ci.hi
http://ci.hibernate.org/job/hibernate-orm-master-h2-main/
http://ci.hibernate.org/job/hibernate-orm-master-h2-check/
Initial attempt
On Sat, Jun 18, 2016 at 12:58 PM Sanne Grinovero
wrote:
> On 18 June 2016 at 18:50, Chris Cranford wrote:
> > +1
> >
> > I think (1) and (2) on each push still m
1 - 100 of 217 matches
Mail list logo
