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 <sanne(a)hibernate.org>
wrote:
On 30 August 2017 at 16:53, Steve Ebersole
<steve(a)hibernate.org> wrote:
>
> On Wed, Aug 30, 2017 at 10:38 AM Sanne Grinovero <sanne(a)hibernate.org>
> wrote:
>>
>> On 29 August 2017 at 20:28, Steve Ebersole <steve(a)hibernate.org> 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 `wildfly-11-dist`. Things that refer to this
>> > artifact
>> > as a dependency would no longer work.
>>
>> Sorry but I'm not understanding. To be clear: I only patched master,
>> so I already updated 5.2 and yes I can confirm that the classifier
>> changed accordingly.
>>
>> I don't see this as a big deal for users, I updated the ORM
>> documentation accordingly to mention the new classifier. IMO changing
>> target appserver is not expected to be "as automatic" as changing
some
>> dependencies, and it's unlikely to not be noticed so having to change
>> the classifier shouldn't be a big deal.
>
>
> Well you are assuming that someone using hibernate-orm-modules going from
> Hibernate version 5.2.10 to 5.2.10 also wants to go from WF 10 to WF
11. I
> don't think that is necessarily a valid assumption. This line of
thinking
> clearly targets people wanting to try the latest Hibernate in the latest
WF.
> If that is the only goal, then this works. But it causes problems for
> people already using
> `org.hibernate:hibernate-orm-module:5.2.10:wildfly-10-dist` - its not
just
> the version that changed so changing a single ~`hibernateVersion`
property
> somewhere is not enough for a simple upgrade for these people.
I'm aware of that and that's why I asked here first.
The alternative being - like I proposed in my first email - that we
start producing both a modules set for WF10 and WF11 for each release
of the 5.2 branch... no doubt that gives users a bit more flexibility
but it's a strong tradeoff on our maintenance, especially on the time
it takes to test both app servers during each build.
A complex tradeoff for sure :)
> My concern is really more along the lines, e.g., of the trouble we ran
into
> with Spring and us dropping hibernate-entity-manager - their BOMs no
longer
> worked as it referred to no-longer-existent artifact. Changing the
> classifier leads to the same condition.
Understood, except that half of the Java developers in the world
depend on hibernate-entitymanager, while needing to patch WildFly to a
specific micro of ORM 5.2 seems like a very restricted circle of
highly specialized people.
I'd suggest we take the risk of breaking this and we can reconsider if
someone from this small circle shows up with persuasive arguments.
Let's bear in mind that we started creating these modules for our own
integration testing needs; we made them available to others too but it
clearly states we only maintain this for the latest version of
WildFly.
Thanks,
Sanne