[hibernate-dev] Plans to release 5.2.13?

[Steve Ebersole]

On Wed, Jan 10, 2018 at 5:41 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> AFAICS, lately, the ORM bugfix releases announcement is just a link to the
> changelog. I don't think it would buy you a lot to automate it.
>

Its been a long time since I've personally done a ORM bugfix release.  But
AFAIK we still do do a detailed "release announcement".  Its just that we
centralize that in one place (the blog) and have the other forms (email,
twitter, etc) simply refer back to that one.  But regardless of how simple
or elaborate these "secondary" announcements are, the information changes
still need to be collected and "written up" - and that's not something that
can really be automated.

Again, the question here was about automating this process of doing a
release.  So everything i am bringing up is in relation to that point.  So
from one POV there are 2 parts to releasing:

   1. the actual release (tagging, publishing artifacts, publishing docs,
   etc)
   2. various announcements (blog, email, twitter, etc)

This "automated release job" people keep bringing up can really only do
some of these tasks.  The "problem" is that those are tasks we have already
"automated" in Gradle itself - having an actual CI job to do the release
really isn't buying us anything.

And btw... the release announcement emails, tweets, forum posts, etc have
been simple links back to the blog post for YEARS.  So not sure what you
mean about that happening "lately".


For the NoORM projects, the announcement part (Twitter, Mail, Blog) is
> still manual. I don't think it's that bad.
>

Of course, because we all like our own devised processes :)

But I can tell you this... the question of the release announcement blog
URL aside... if I could automate the announcement to the "other forms", I
absolutely would.  And I think you'd be lying if you said you wouldn't want
to.




> I think we agree on the principles. We just need to have a viable
> definition of "stable" for the users.
>

Its more than having a definition of "stable".  Perhaps that's the
problem.  Technically ORM 2.0 is still "stable".  We normally mean that as
a counter-point to "(in) development".  So just like 2.0 is stable, so are
3.0, 4.0, 5.0, 5.1, 5.2, etal.

"Stable" is really just "beyond the pre-release versions" (Alpha, Beta,
CR)... in other words: Final.  So once we release 5.3.0.Final, 5.3 is
"stable".  But 5.2 is also still "stable".  So its not this
"stable"/"development" that is the important distinction here.  Its really
more about "current" (or "active") versus "older".  So at the time of
5.3.0.Final, that's the more important transition here - 5.3 becoming the
*current* stable release.


Could we agree on releasing it regularly from now on and at least plan a
> 5.2.13 release soon to release all the fixes already in?
>

In isolation 5.2 is not what we should be recommending to use - once 5.3
goes Final for sure.  5.2 -> 5.3 does have a minor hitch in this though in
that it also represents a bump in JPA version.  Which means that a user is
not going to be able to simply drop 5.3 on top of 5.2 in a container (EE,
Spring, etc) written to work with JPA 2.1.

But even given that, I still think we are only going to do a limited number
of additional 5.2 releases, stopping once 5.3 becomes stable.

The real question is who is going to handle:

   1.  identifying what should get ported from 5.3/master to 5.2
   2. performing the needed back ports
   3. performing the release(s)

Because the longer y'all want 5.2 releases to continue, the more help we
are going to need