[hibernate-dev] Plans to release 5.2.13?

[Steve Ebersole]

BTW Gail... back to part of your original question... a branch in git is
very cheap, so I like create a branch anytime we jump to a new "line of
development".  It's just much more flexible moving forward.  So yes, there
is a 5.2 branch - but that does not mean we have to do something with it
(backport e.g.)

On Fri, Jan 5, 2018 at 9:24 AM Steve Ebersole <steve at hibernate.org> wrote:

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