On 11 April 2017 at 10:24, Gunnar Morling <gunnar(a)hibernate.org> wrote:
On the group id, I'd prefer to keep it as is. This will make it less
disruptive if dialects are demoted/promoted between contrib and core.
On the license I also think it needs to remain as is.
Overall, I'm still unsure what's the implication of the split
the lifecycle of dialects is going to look like. Will there be a
release of the contrib repo's dialects whenever core is released? What
does it mean if a dialect is in contrib? Will it be ensured that it
generally works with the latest OGM, but it will not benefit from any
new optimizations in core? How will people know which versions work
This is very important to clarify, as it's supposed to be "the" reason
for the split.
As far as I understood from our previous debates, the problem being
addressed is that we have no bandwidth / interest in maintaining all
So if that's the case, I believe it's important that *we will allow*
for the main repository to go ahead with new development and releases
while not necessarily bringing the contrib dialects on par.
This implies that the "contrib" dialects will not necessarily be
released for each latest version of OGM and there might be gaps in
The problem I see with this, is that not all "contrib dialects" will
be equal. So while someone might want to volunteer to bring dialect A
up to speed with latest OGM versions, they will want to see it
released and yet we might not have been able to update the other
dialects in the contrib repository: the other dialects being in bad
state shouldn't block the ones ready for a release.
So we need to be able to release each contrib dialect independently. I
probably wouldn't use a single repository for them, this clearly is a
set of different projects depending on OGM/core.
I'd probably be a good idea to have a document describing the policies
and lifecycles around these modules and the repo split.
Did you take a look at how it's done in Spring Data btw.? There
have a repo per datastore, each with their own release cycle AFAIKU.
And then there are "release trains", which essentially is a family of
releases of the datastores, with all matching versions grouped in a
BOMs are dead. Long live modules!
+1 for trains, but allow gaps please.
For example there might be no interest in getting all dialects updated
for 5.2 - while they existed for 5.1 - and yet someone might want to
restore some of them for 5.3.
That model seems the most flexible in terms of independent releases,
and it'd also allow to abandon a specific datastore if no one steps up
to maintain it (by excluding it from the next release train), but I
could imagine the plethora of repos and required releases doesn't make
it easy to manage necessarily.
2017-03-28 13:08 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
> Regarding the License I think we have no choice, we have to use the
> same license as alternatively we'd need to get permission to change
> the license as it's existing code.
> I'm assuming we have no interest in that, and if we had this process
> would take some time so we'd have to propose such a change as an
> independent step from the repository move.
> Regarding group-id : I see no reason to change it but have no strong
> opinion on that. I'd similarly suggest to make such changes as a
> follow-up though, and not treat it as a blocker.
> (If we decide to change it, it would be a breaking change so we'd need
> redirection poms so we might as well do it later)
> On 28 March 2017 at 11:28, Davide D'Alto <davide(a)hibernate.org> wrote:
>> Hi all,
>> I've moved the contributed dialect for OGM in this repository:
>> I have a couple of quesitons before moving it in an official repository:
>> - Which group id should we use? At the moment it is still
>> org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib
>> - What about the license? Can I re-use the same in Hibernate OGM?
>> I still need to update the README, this is the related PR for OGM:
>> hibernate-dev mailing list
> hibernate-dev mailing list