We discussed stopping 5.2 releases at the F2F, but I can't remember what was decided. I see that there is a 5.2 branch. Should we be backporting to 5.2 branch? Thanks, Gail _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi, AFAICS there are 52 issues fixed for 5.2.13. And there are a couple of PRs waiting for review AFAICS (which might be ready to be integrated or not). So I think it would be really beneficial to continue doing 5.2.x releases. 5.3 is not there yet. And once it's going to be released, we would still need the integrators to support it (be it WildFly or Spring) before considering it fully consumable by the end users. And probably some time to get it field tested too before we can consider 5.2 as being more or less "dead" and just say to the users "upgrade to 5.3". My 2 cents. -- Guillaume On Fri, Jan 5, 2018 at 12:53 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > We should definitely stop doing 5.2 releases once we release 5.3. > > Of course 5.3 is held up waiting for answers from a few people... > > On Thu, Jan 4, 2018, 7:29 PM Gail Badner <gbadner(a)redhat.com&gt; wrote: > > > We discussed stopping 5.2 releases at the F2F, but I can't remember what > > was decided. > > > > I see that there is a 5.2 branch. Should we be backporting to 5.2 > branch? > > > > Thanks, > > Gail >

Hi, AFAICS there are 52 issues fixed for 5.2.13. And there are a couple of PRs waiting for review AFAICS (which might be ready to be integrated or not). So I think it would be really beneficial to continue doing 5.2.x releases. 5.3 is not there yet. And once it's going to be released, we would still need the integrators to support it (be it WildFly or Spring) before considering it fully consumable by the end users. And probably some time to get it field tested too before we can consider 5.2 as being more or less "dead" and just say to the users "upgrade to 5.3".

My 2 cents. -- Guillaume On Fri, Jan 5, 2018 at 12:53 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > We should definitely stop doing 5.2 releases once we release 5.3. > > Of course 5.3 is held up waiting for answers from a few people... > > On Thu, Jan 4, 2018, 7:29 PM Gail Badner <gbadner(a)redhat.com&gt; wrote: > > > We discussed stopping 5.2 releases at the F2F, but I can't remember what > > was decided. > > > > I see that there is a 5.2 branch. Should we be backporting to 5.2 branch? > > > > Thanks, > > Gail > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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.

But even on top of that stuff, its often just managing the backporting that is resource intensive - identifying what should be backported and what should not, not to mention managing the conflicts as we get further down that path.

On Fri, Jan 5, 2018 at 8:23 AM Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: > On Fri, Jan 5, 2018 at 2:32 PM, Steve Ebersole <steve(a)hibernate.org&gt; > 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

at least plan a 5.2.13 release soon to release all the fixes already in?

Hi, On Fri, Jan 5, 2018 at 4:24 PM, Steve Ebersole <steve(a)hibernate.org&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

And btw... the release announcement emails, tweets, forum posts, etc have been simple links back to the blog post for YEARS. So not sure what you mean about that happening "lately".

For the NoORM projects, the announcement part (Twitter, Mail, Blog) is > still manual. I don't think it's that bad. > Of course, because we all like our own devised processes :) But I can tell you this... the question of the release announcement blog URL aside... if I could automate the announcement to the "other forms", I absolutely would. And I think you'd be lying if you said you wouldn't want to.

> definition of "stable" for the users. > Its more than having a definition of "stable". Perhaps that's the problem. Technically ORM 2.0 is still "stable". We normally mean that as a counter-point to "(in) development". So just like 2.0 is stable, so are 3.0, 4.0, 5.0, 5.1, 5.2, etal. "Stable" is really just "beyond the pre-release versions" (Alpha, Beta, CR)... in other words: Final. So once we release 5.3.0.Final, 5.3 is "stable". But 5.2 is also still "stable". So its not this "stable"/"development" that is the important distinction here. Its really more about "current" (or "active") versus "older". So at the time of 5.3.0.Final, that's the more important transition here - 5.3 becoming the *current* stable release.

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.

But even on top of that stuff, its often just managing the backporting that is resource intensive - identifying what should be backported and what should not, not to mention managing the conflicts as we get further down that path.

On Fri, Jan 5, 2018 at 7:16 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > > On 5 January 2018 at 13:05, Guillaume Smet <guillaume.smet(a)gmail.com&gt; > wrote: > > Hi, > > > > AFAICS there are 52 issues fixed for 5.2.13. > > > > And there are a couple of PRs waiting for review AFAICS (which might be > > ready to be integrated or not). > > > > So I think it would be really beneficial to continue doing 5.2.x > > releases. > > > > 5.3 is not there yet. And once it's going to be released, we would still > > need the integrators to support it (be it WildFly or Spring) before > > considering it fully consumable by the end users. And probably some time > > to > > get it field tested too before we can consider 5.2 as being more or less > > "dead" and just say to the users "upgrade to 5.3". > > +1 I'd love to see more regular OGM releases, and some benevolent > maintenance time on 5.2 for a while longer even after 5.3 is > available. > > We're all willing to help with the release process, including automate > it more; if someone on the ORM team could volunteer brains for the > organizational work we can make sure it's quick and painless by > delegating the annoying labour to Jenkins. > > Thanks, > Sanne > > > > > My 2 cents. > > > > -- > > Guillaume > > > > On Fri, Jan 5, 2018 at 12:53 PM, Steve Ebersole <steve(a)hibernate.org&gt; > > wrote: > > > >> We should definitely stop doing 5.2 releases once we release 5.3. > >> > >> Of course 5.3 is held up waiting for answers from a few people... > >> > >> On Thu, Jan 4, 2018, 7:29 PM Gail Badner <gbadner(a)redhat.com&gt; wrote: > >> > >> > We discussed stopping 5.2 releases at the F2F, but I can't remember > >> > what > >> > was decided. > >> > > >> > I see that there is a 5.2 branch. Should we be backporting to 5.2 > >> > branch? > >> > > >> > Thanks, > >> > Gail > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev