I actually think ORM 4.4 stabilizing the APIs and SPIs used in the other projects would be a good idea as well.
On Mon, Jul 14, 2014 at 5:54 AM, Sanne Grinovero <sa...@hibernate.org> wrote: > Good point on OGM' s need for a specific micro. We could propose a 4.4 > series of ORM after you finish defining the integration point? So OGM > x.Final will be able to depend on a more reasonable version range. > > About BOM files, I'm just skeptical as I don't see how we should > maintain and test them: > - would we update some separate BOM project at every release? > - would you re-run the testsuite of each and all projects at every BOM > update overriding the testsuite versions to make sure it's a valid > combination? (how to automate?) > - I'd also expect some integration tests to actually verify the > correctness of the BOM file (e.g. syntax) > > Also the documented dependency ranges on the website could need some > testing in a perfect world, but: > a) I'd expect it to be simpler as it' s a smaller matrix if each > project documents its own dependencies only > b) each project somehow "is aware" if when it breaks compatibility > with older dependencies, like you notice now with OGM: it's an > explicit step you just have to remember to document (and rare enough > so that I wouldn't bother too much to automate). > c) *Personal opinion* I feel like a statement about *expected > compatibility* does create a lower expectation in terms of accuracy > than a BOM file, so that I wouldn't expect need for actual QA on this > subject as much as I would expect it on BOM files which we would > officially distribute. > > I'm not strictly against BOM but it sounds like taking a lot of our > bandwidth for a minor practical improvement. > > > Ultimately we should be very aware that our modules are in constant > change, and people mixing our latest are aware of a little bit of risk > in using latest as there is a mismatch between our expectations vs our > capacity to test and deliver a single unified platform, I think that's > more something for assemblies such as WildFly, JBoss EAP, Spring, and > whoever else redistributes our jars as a combination. We should be > ready to provide recommendations (as what we expect to work) to the > people making these distributions and our users but.. would you > consider untested BOM files to be good for that? > > Sanne > > > On 14 July 2014 11:21, Gunnar Morling <gun...@hibernate.org> wrote: > > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero <sa...@hibernate.org>: > > > >> I've been explaining $subject to a forum user [1]. I'm confident it's > >> only a problem for newcomers, but are we expecting more expert > >> developers to pass this lore by word of mouth? > > > > > > Not so sure whether it's not a problem for expert users as well every now > > and then. > > > > Looking at OGM for instance, we're currently in the situation that we > depend > > on a specific micro version of ORM (4.3.6 once it's out), which may be a > > surprising fact. Personally, I think it'd be rational for a user to > expect > > compatibility based on minor version families of our projects, e.g. that > > each OGM 4.1.x release is compatible with each ORM 4.3.x release. > > > > As we can't guarantee this due to the rapid evolvement atm. (e.g. we add > new > > SPIs in ORM micro releases for the sake of OGM), some clear > documentation is > > highly desirable. > > > >> I think we should add an explanation on these on the website but I'm > >> not sure where this would be more appropriate to present. > >> > >> Should we highlight compatible versions of other integration points on > >> each sub section? > >> For example I could edit the Search area to mention which versions of > >> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two > >> different ones!), Commons Annotations, etc.. are supposed to work for > >> each release. > > > > > > Documenting the matching/required versions of upstream projects in each > > project area may be one way. E.g. Search could document its requirements, > > OGM its own etc. I don't think Search should document any expectations > > towards OGM versions as the dependency is the other way around? > > > > Speaking in Maven terms, I still think that providing this information in > > form of bill-of-materials POMs would be the approach most helpful to > users. > > Such project BOM would contain the versions of all its components and > > dependencies. Users would reference this BOM using the "import" scope in > > their dependency management configuration and thus get matching versions > > when declaring a dependency to any of the artifacts listed in the BOM. > > > > I vaguely remember though that in the past there had been reservations > > towards providing such BOMs? > > > > @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574 to > do > > this for OGM; Shall we give it a try? > > > > --Gunnar > > > > > >> > >> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292 > >> > >> -- Sanne > >> _______________________________________________ > >> 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
