[hibernate-dev] Plans to release 5.2.13?

[Guillaume Smet]

Hi,

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

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

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.

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


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

I did a quite a lot of regression hunt myself in $previousJob (mostly on
Search but a bit on ORM too), and it did help to upgrade often and when the
releases were not too big. Easier to find the commit causing the regression.

I don't know if there are a lot of companies doing that (I know mine
stopped to do that after I left) but it did really help to upgrade in
smaller steps.

That's what I was trying to explain.

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 think we agree on the principles. We just need to have a viable
definition of "stable" for the users.


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

So I think we all agree that the situation with 5.2 is less than ideal.

And it's the version currently recommended for community usage. Which is a
large part of Hibernate usage.

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?

Thanks!

-- 
Guillaume