[hibernate-dev] Plans to release 5.2.13?

[Guillaume Smet]

On Fri, Jan 5, 2018 at 2:32 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Certain parts of the release process are easy to automate, assuming
> nothing goes wrong of course.  Other parts are not.  Which actually circles
> back to some things I've been comtemplating about (ORM at least) releases.
> Basically we have an elaborate set of steps we go through for a release
> beyond just the "simple" aspects like tagging, building/uploading jars...
> things like blog posts, forum announcements, announcement emails... and we
> do these even for each bug fix release.  IMO we really should only be doing
> some of these for a family (5.2, 5.3) initially going stable (Final).  I'd
> love to see the release task (the actual Gradle tasks) do an announcement
> when any release is performed - Gradle has an "announce" plugin that can
> announce via twitter, etc.  To me that is enough for a generalized "hey
> this new release it out" notifications.  The initial stable release of a
> family (5.2.0.Final, 5.3.0.Final, 6.0..0.Final...) is special and the one
> we should handle specially by doing some of  these other things.
>

It should take no more than half a day to do the release itself. A full day
with a detailed blog post.

I agree it's still one day not spent on other things. But having a release
per month should be doable. In the case of 5.2.13, we are talking about
nearly 3 months of work that are not in the hands of the users.

If you release something every month, it's not that bad if a bugfix slips
to the next release. If a PR is not completely ready, well, it's going to
be in the next one, no need to wait. It helps getting the release
coordination easier.

It's also easier to detect and fix regressions when you release more
frequently.

The good thing is that we are not considering a bugfix release as something
traumatizing anymore. It's just day to day work.


> But even on top of that stuff, its often just managing the backporting
> that is resource intensive - identifying what should be backported and what
> should not, not to mention managing the conflicts as we get further down
> that path.
>

That I can understand. But I think not releasing periodically doesn't help
as if you backport a 3 months old fix, it's hard to go back to it then.

FWIW, in the active community branches, I usually do the backport right
away - if I think the issue requires backporting, sometimes, it's just not
worth it or too risky. And I'm doing the "what should I backport?" thing
only on product only branches.

I'm not saying it would be that easy with ORM as the flow of issues is
significantly larger. Just stating how we do it.

-- 
Guillaume