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 <st...@hibernate.org> wrote: > On Fri, Jan 5, 2018 at 8:23 AM Guillaume Smet <guillaume.s...@gmail.com> > wrote: > >> On Fri, Jan 5, 2018 at 2:32 PM, Steve Ebersole <st...@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 > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
