[hibernate-dev] Explaining versioning and dependency compatibility

[Steve Ebersole]

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 <sanne at 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 <gunnar at hibernate.org> wrote:
> > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero <sanne at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>