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
