Then not sure why you ask if you already plan on your answer ;)
On Mon, Jul 2, 2018 at 5:48 PM Guillaume Smet
wrote:
> On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole wrote:
>
>> 1) That was specifically requested
>>
>
> Sure. And we also have users who are unhappy with the new setup.
>
> This
On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole wrote:
> 1) That was specifically requested
>
Sure. And we also have users who are unhappy with the new setup.
This was also changed for the legacy Ehcache 2 provider which is a pity
IMHO.
> 2) This is easily handled by the providers, if they
+1 for 5.3 branch
On Mon, 2 Jul 2018, 19:05 Gail Badner, wrote:
> +1 on creating a 5.3 branch, with master being used for 5.4 (or 6.0).
>
> On Mon, Jul 2, 2018 at 9:43 AM, Sanne Grinovero
> wrote:
>
> > On Mon, 2 Jul 2018 at 17:34, Steve Ebersole wrote:
> > >
> > > I don't mind creating a 5.3
Yes, what you describe is exactly the hybrid approach I suggested.
On Mon, Jul 2, 2018 at 3:52 PM Vlad Mihalcea
wrote:
> The short name approach sounds goid and would accommodate any future cache
> region implementation changes.
>
> For 5.3, I'd say we allow the old named to be resolved to the
The short name approach sounds goid and would accommodate any future cache
region implementation changes.
For 5.3, I'd say we allow the old named to be resolved to the new ones,
like symbolic links.
This will allow users to migrate to 5.3 without changing existing
ehcache.xml configs.
We could
1) That was specifically requested
2) This is easily handled by the providers, if they wish. They would
simply map any undefined regions/caches to a pre-defined one (probably
after warning the user). Keep in mind that region != cache. A provider
might map multiple region names to a single
+1 on creating a 5.3 branch, with master being used for 5.4 (or 6.0).
On Mon, Jul 2, 2018 at 9:43 AM, Sanne Grinovero wrote:
> On Mon, 2 Jul 2018 at 17:34, Steve Ebersole wrote:
> >
> > I don't mind creating a 5.3 branch, and having master for "after 5.3"
> development with 6.0 hopefully
On Mon, 2 Jul 2018 at 17:34, Steve Ebersole wrote:
>
> I don't mind creating a 5.3 branch, and having master for "after 5.3"
> development with 6.0 hopefully merged in there soon.
+1 that sounds like the best option we have. It's not extremely
urgent, we can do this after 5.3.2 ?
Just making
I don't mind creating a 5.3 branch, and having master for "after 5.3"
development with 6.0 hopefully merged in there soon.
On Mon, Jul 2, 2018 at 11:23 AM Steve Ebersole wrote:
> I think I have pointed out before that such a schedule is already posted :
>
I think I have pointed out before that such a schedule is already posted :
https://github.com/sebersole/hibernate-core/blob/wip/6.0/design/6.0-todo.adoc#alpha1
The important part remaining is really collection support.
There are a few listed there that we'd be willing to push to the next Alpha
Hi Steve,
Glad to have you back! Hope yo got some rest.
On Mon, Jul 2, 2018 at 5:28 PM Steve Ebersole wrote:
> Overall what I would suggest is a hybrid approach where we move to a
> "short name" solution much like we have for most other config values. So,
> e.g., the name of the default query
Hi Sanne,
On Mon, Jul 2, 2018 at 5:48 PM Sanne Grinovero wrote:
> Not sure what to suggest to people wanting to contribute new features
> today; maybe hold as we assume the 6.0 work will be merged in master
> soon? Will be hard to say no to many reasonable requests though.
>
IMHO, there are 2
If 5.3 cannot take new features, it's better to branch it and have a 5.4
branch for the master until 6.0 is ready.
There are lots of interesting improvements that are provided via PRs or as
suggestions on the forum, so it would be detrimental to our users to delay
those until 6.0 can be used in
On Hibernate ORM we're currently having "master" branch essentially
being a maintenance branch, aka master today is what's planned to be
version 5.3.2.Final in some days, 5.3.3 later, etc..
This is quite unusual, and it begs some extra attention: normally we'd
start a new minor in master, so that
Changing the name of the default query results cache I can see being a
problem in retrospect. That is something the user might want to
configure.
I am much less convinced about the update-timestamps cache. I guess it
would depend on what they are configuring.
Overall what I would suggest is a
Hi all,
So following our off-list discussions , I wanted to share a document we
wrote with Yoann with some details about the usability/compatibility of the
new cache implementation in 5.3:
https://docs.google.com/document/d/19xmsWlYOkXeAnZlEjcxFy6SUitxmT1JywoDyX22TrvE/edit?usp=sharing
(The
Hi Sanne,
*JDK 11 is now in Rampdown Phase one***
The overall feature set is frozen. No further JEPs will be targeted to
this release.We’ve forked the main-line source repository, jdk/jdk, to
the jdk/jdk11 stabilization repository. Any changes pushed to jdk/jdk or
jdk/client are now bound for
17 matches
Mail list logo
