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 <sa...@hibernate.org> wrote: > On 11 April 2017 at 10:24, Gunnar Morling <gun...@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 <sa...@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 <dav...@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@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
