Hi, On Fri, Jan 5, 2018 at 4:24 PM, Steve Ebersole <st...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
