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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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.

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?

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

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.

--Gunnar 2017-03-28 13:08 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > 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(a)hibernate.org&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)hibernate.org&gt; wrote: > On 11 April 2017 at 10:24, Gunnar Morling <gunnar(a)hibernate.org&gt; 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(a)hibernate.org&gt;: >>> 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(a)hibernate.org&gt; 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev