[hibernate-dev] Regarding release versioning

Steve Ebersole steve at hibernate.org
Wed Jun 8 10:32:16 EDT 2016

On Wed, Jun 8, 2016 at 9:20 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>

> If there is a backward incompatibility issue, we catch it in the CR
> release and, by the time we release Final, we know we got it fixed.

If I had to guess, this is what Spring Data devs are more interested in.
We have been doing a lot of refactoring in 5.x.

> So, with a CR, we just buy more time. Not only that we have OGM and Search
> to provide feedback on the latest CR releases, but even the Spring Data
> team tries to integrate our latest artifacts into their platform.

But see "buying more time" is not necessarily a good thing.  Because really
here that means allow the release to take more time:

   - allow it more bake time - obviously that's ok, within reason
   - more discussion - again ok, within bounds.  For example, each and
   every one of the major changes in 5.2 was discussed in specific on dev
   channels as it was being designed and developed.  Again, its all about
   - more time to physically do releases - it takes me roughly half a day
   to do a release.  Between running the release build, fighting Nexus,
   changing the website, announcing, etc.  Those half days add up

So let's be careful here.  Go back to the original discussion.  We used to,
quite bluntly, waste a lot of time just doing release-y things.  It sucks
when I barely have time to dev as it is, and now I have to take some of
that time and invest it back into release-y stuff.

Many end-user applications will never try the CR releases, so they will
> just go to Final versions which are more stable.

Exact same argument for SNAPSHOT :)

More information about the hibernate-dev mailing list