[hibernate-dev] [OGM] Hibernat OGM contrib repository

[Davide D'Alto]

If I understand correctly the consensus for the contrib dialects is:

* Keep the same group id of core: org.hibernate.ogm
* Keep the same license we use in OGM
* Create a repository per dialect: each repository will have it's own
life-cycle, it will depend on core and it won't impact the other
dialects.

I'm not sure if I like the idea to have a repository per dialect in
term of maintenance but it seems the most flexible approach.

Would that work for everybody?

Thanks,
Davide

On Tue, Apr 11, 2017 at 10:39 AM, Sanne Grinovero <sanne at hibernate.org> wrote:
> On 11 April 2017 at 10:24, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Hi,
>>
>> 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.
>
> +1
>
>> Overall, I'm still unsure what's the implication of the split and how
>> 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
>> together?
>
> 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
> of them.
> 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
> compatibility.
>
> 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.
>
> +1
>
>> Did you take a look at how it's done in Spring Data btw.? There they
>> 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
>> BOM.
>
> BOMs are dead. Long live modules!
>
> </joke>
>
> +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.
>
> Thanks,
> Sanne
>
>
>>
>> --Gunnar
>>
>>
>>
>> 2017-03-28 13:08 GMT+02:00 Sanne Grinovero <sanne at 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)
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>> On 28 March 2017 at 11:28, Davide D'Alto <davide at hibernate.org> wrote:
>>>> Hi all,
>>>> I've moved the contributed dialect for OGM in this repository:
>>>> https://github.com/DavideD/hibernate-ogm-contrib
>>>>
>>>> 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:
>>>> https://github.com/hibernate/hibernate-ogm/pull/850
>>>>
>>>> Thanks,
>>>> Davide
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev