On 17 April 2017 at 16:32, Davide D'Alto <dav...@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 <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
