Hey all, > at least plan a 5.2.13 release soon to release all the fixes already in?
+1 for doing another 5.2 release if there are lots of issues already merged and 5.3 isn't going through the door very soon. It'd be great to get those nice fixes you all did out to users. I realize I won't be the one doing this work, so consider it just as my 2c, but from the sidelines it seems like an effort well spent. Cheers, --Gunnar 2018-01-10 12:41 GMT+01:00 Guillaume Smet <guillaume.s...@gmail.com>: > 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
