Branch protections: enabling selected maintainers on older branches
by Sanne Grinovero
Hi all,
yesterday I pushed a fix on Hibernate ORM branch 5.3 by mistake and
had to apologize to Gail, since we're to be very conservative with
that branch and she needs to be able to track and approve any changes
on this specific branch.
This made me check if there was a way to express such rules on github,
and there is: the "branch protection" feature can now apply different
rules, such as requiring to be a member of a specific team, on a
specific branch.
I like that: we can allow most current committers to keep working on
any branches in active development, such as master, while only a more
restricted group can push freely on selected older branches.
Of course admins can always change the settings if there's compelling
need; in this case I like the self-imposed restriction as it would
help avoid mistakes - such as trying to be helpful when too tired.
So I enabled this on 5.3 already .. I hope you agree it's a welcome
change, but we can of course reverse this if there's strong concerns,
or if we regret it later.
Thoughts? I'd assume other Hibernate projects might want to do a
similar thing; among other benefits it might make it easier to give
push permissions to new volunteers, withouth needing to impose on them
all the responsibilities and more complex processes we have for
maintenance branches.
Thanks,
Sanne
5 years, 5 months
Re: [hibernate-dev] #3401
by Sanne Grinovero
Thanks for the heads up, I had not noticed this PR.
We're planning an ORM release in the early afternoon - mainly as
Quarkus has the code freeze tonight and there are some bugfixes they
will need. So let's try to get all Reactive things in too - but if
they aren't ready by approx ~15h today we can do another release in a
few days.
They all seem simple enough so just push it:)
On Mon, 18 May 2020 at 11:26, Gavin King <gavin.king(a)gmail.com> wrote:
>
> We need to get this pull request on ORM applied ASAP, since it's
> currently blocking us from doing work.
>
> --
> Gavin King
> IBM
5 years, 5 months
Hibernate Search 6.0.0.Beta7 released
by Yoann Rodiere
Hello,
We just published Hibernate Search 6.0.0.Beta7.
This release mainly improves sorts and aggregations on multi-valued or
nested fields, introduces dynamic index fields through field templates,
restores the index metamodel, and restores low-level Lucene settings.
It also includes an upgrade to Hibernate ORM 5.4.15.Final.
For more information, see our blog:
https://in.relation.to/2020/05/11/hibernate-search-6-0-0-Beta7/
Yoann Rodière
Hibernate Team
yoann(a)hibernate.org
5 years, 6 months
HHH-13936 PR pending acceptance
by Michiel Hendriks
I have a request regarding issue: HHH-13936 "No auto transaction joining
from SessionImpl.doFlush": https://hibernate.atlassian.net/browse/HHH-13936
I logged this a month ago with a pull request containing a fix:
https://github.com/hibernate/hibernate-orm/pull/3335 (The travis
notification of a passed build apparently didn't come through.)
As far as I can tell this hasn't received any attention. I think I followed
all the correct procedures.
This issue is a major blocker for us to upgrade to Hibernate 5.
I'm now reaching out to you via the mailing list because I'm leaving this
company quite soon and basically want to resolve this last thing.
All I need is the confirmation that this fix will be accepted and available
in the next 5.4 release. Then I can go ahead and merge our hbm 5 upgrade
using a local snapshot build containing this fix.
thanks,
Michiel
--
Michiel Hendriks, MSc
System Architect
MPO
✉️ michiel.hendriks(a)mpo.com
🌐 www.mpo.com
☎️ +31 102900304
5 years, 6 months
Toward the first Hibernate Reactive release
by Emmanuel Bernard
Hey everyone,
The work around Hibernate Reactive is coming along nicely. So has some
other work needed on the Vert.x front and Mutiny front. Now is time to
ship a first version to the community. With some of the people working
on it, I've tried to come up with a list of tasks and decisions to make.
And proposed decisions to avoid blockers.
## Communication
Most communication happens on the project Pull Request, a good thing I
think. But the glue between them was missing as far as communication.
I propose we use hibernate-dev@ for this.
## The project name
There is an open PR related to the name of the project
https://github.com/hibernate/hibernate-rx/issues/77
I exchanged with Gavin and Sanne and went back and forth on it.
My preferred name _was_ `Hibernate ORM Reactive` because of the fight we
did to make `Hibernate` != `Hibernate ORM` brand wise. But we have quite
failed to convert the general public :) As a brand, `Hibernate Reactive`
is strong and catchy. The only project besides ORM that could become
reactive is Search (I don't think validator has a strong case). We
likely should swallow our pride and call the project `Hibernate
Reactive`. If HSEARCH reactive comes up, we could use `Hibernate
Reactive Search`.
So unless someone is strongly against it, let's call it `Hibernate
Reactive` which would be our sub umbrella for our reactive work.
Frankly, the other names were too incorrect or suck for a brand. There
is also the strong possibility that we would want to deliver all
Hibernate Reactive subprojects as one to be able to combine them.
That means renaming the doc and the package, the GitHub repository and
the Quarkus Extension. This will only be done after Query support is
initially pushed not to disrupt things too much.
## Query support
I strongly think that we need Query support for the initial release. It
can be an initial Query support. But we need something. This is the one
technical subject that prevents us from releasing Hibernate Reactive
alpha. Davide is working on it and we will know more in a week or two
about the viability status.
As soon as there is shared code (working or not), Gavin offered to help.
## Mutiny
https://github.com/hibernate/hibernate-rx/issues/94
Mutiny will be a first class API for Hibernate Reactive. Gavin is
working on building it.
## One module to rule them all
Today we have an API module and an Impl module. But reality is we don't
know how we will split the project if any. This highly depend on the API
reaction and popularity.
With Mutiny coming in, the API module became a bit complicated.
Gavin proposed to merge everything in one module during the alpha / beta
stage of the project and reevaluate with user feedback. This will only
be done after Query support is initially pushed not to disrupt things
too much.
## Quarkus extension
https://github.com/quarkusio/quarkus/pull/9060
Andy did an awesome work into fleshing out the initial Quarkus
Extension. Even better, it works for native for the main path :)
The main annoyance is that to generate schema, you need a JDBC driver
setting and a JDBC driver in your classpath. We can improve on that but
that's not a trivial amount of work to adapt `SchemaExport` and friends.
## Documentation
Right now we have the readme as documentation. The proposed idea is as
followed:
- we convert the readme content (or get inspired from it) and generate a
Quarkus guide out of it. Their format are really similar.
- best would be to convert the [Quarkus Hibernate ORM
quickstart](https://github.com/quarkusio/quarkus-quickstarts/tree/develop...
to use Hibernate Reactive and base the guide on it.
- a more formal documentation and working for Hibernate Reactive
standalone (outside of Quarkus) can grow from these. See website
section.
## Blog
We need to work on a blog announcing the project.
## Website
We need to adapt hibernate.org to have a Hibernate Reactive project.
Once you make Awestruct work, it should be a relatively quick change to
add the relevant sections. There is likely quite some work on the
various messages and content of the key sections.
Once we have all or most of this, we can release and get user feedback
:)
When? To that, I'd quote a wise man from the future
**Lt. Commander Geordi La Forge:** Look, Mr. Scott, I'd love to explain
everything to you, but the Captain wants this spectrographic analysis
done by 1300 hours.
[La Forge goes back to work; Scotty follows slowly]
**Scotty:** Do you mind a little advice? Starfleet captains are like
children. They want everything right now and they want it their way. But
the secret is to give them only what they need, not what they want.
**Lt. Commander Geordi La Forge:** Yeah, well, I told the Captain I'd
have this analysis done in an hour.
**Scotty:** How long will it really take?
**Lt. Commander Geordi La Forge:** An hour!
**Scotty:** Oh, you didn't tell him how long it would really take, did
ya?
**Lt. Commander Geordi La Forge:** Well, of course I did.
**Scotty:** Oh, laddie. You've got a lot to learn if you want people to
think of you as a miracle worker.
Emmanuel
5 years, 6 months
Jakarta EE 9 / JPA 3: reverting changes from master
by Sanne Grinovero
Hi all,
in previous emails I mentioned I suggested to release a JPA3
compatible version of Hibernate ORM out soon, as I expected this to be
the natural way forward, and soon to be needed by other projects such
as WildFly. I had started working on this myself.
However, the WildFly team hasn't decided if/when they will adopt the
new Jakarta EE APIs, and I've been advised by many that this upgrade
is unlikely to be in high demand:
it brings no new benefits at all, while it introduces quite some
annoying breaking changes.
We have a fairly complete prototype in the draft PR I've sent here:
- https://github.com/hibernate/hibernate-orm/pull/3373
And yet, I think I'll "put it in the freezer". Unfortunately I had
already merged some preparations work in 5.5, such as upgrading to
Validator 7.x: I will revert those changes, apologies for that mess
but I think it's for the best to postpone this for later.
When there will be more interest in this, it should not be too hard to
adapt the work as it's mostly strucutured in the form of replacement
scripts which should apply nicely w/o any conflict even on future
branches.
Thanks,
Sanne
5 years, 6 months
