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

[Sanne Grinovero]

On 17 April 2017 at 16:32, Davide D'Alto <davide at hibernate.org> wrote:
> 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?

Looks good to me!

Thanks,
Sanne

>
> 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