[hibernate-dev] Plans to release 5.2.13?

[Steve Ebersole]

On Fri, Jan 5, 2018 at 8:23 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> 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.
>

Yep, I know how long it takes to do a release - I've been doing them for
almost 15 years ;)

I'm not sure if you are agreeing or disagreeing about blogging every bugfix
release.  But anyway, Sanne asked what would help automate the release
process, so I am listing things that would help.  Of course you can feel
free to contribute blogging and emailing announcement plugins for Gradle
for us to use in the automated release tasks ;)


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.
>

5.2 just got lost in the cracks as Andrea, Chris and I were all working on
6.0.


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

That's a fallacy.  Or at least its not true in isolation.  It depends on
the things that would highlight the regression picking up that release and
playing with it, since your entire premise here is that the regression is
not tested as part of the test suite.  But that's actually not what happens
today in terms of our inter-project integrations... really we find out many
releases later when OGM or Search update to these newer ORM releases.



> 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.
>


This right here is the crux - "active community branch".  By definition no
branch is in active community development.  Again, we have discussed this
as a team multiple times.  Once the next release is stable we stop
developing the previous one, with a few caveats.  E.g.:

   - Once 5.3 is stable we do generally expect to do a *few* additional 5.2
   releases.  But let's be careful about the expectation about the phrase
   "few" here.  I really mean one or 2...
   - For major releases (5.x -> 6.x) we generally expect to do a larger
   number of releases of the 5.3 line.  Again though, not indefinite.

The basic gist is that we are an open source community.  We simply do not
have the resources to maintain infinite lines of development.  We need to
focus on what is important.  I think we all agree that currently 5.2 is
still important, but I think we may all have different expectations for
what that means moving forward as 5.3 becomes the stable release.  I cannot
give a concrete "we will only do X more 5.2 releases after 5.3 is stable"
answer.  It might be 2.  It might be 3.  And it might be 1.


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.
>

Sure.  And time-boxed releases are what we normally strive for as well in
ORM.  5.2 is largely an aberration in this regard.  Again - Andrea, Chris
and I were focused on 6.0 work and since there is no 5.2 based Red Hat work
this fell between the cracks