On Wed, Jan 10, 2018 at 5:41 AM Guillaume Smet <guillaume.s...@gmail.com> wrote:
> 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. > Its been a long time since I've personally done a ORM bugfix release. But AFAIK we still do do a detailed "release announcement". Its just that we centralize that in one place (the blog) and have the other forms (email, twitter, etc) simply refer back to that one. But regardless of how simple or elaborate these "secondary" announcements are, the information changes still need to be collected and "written up" - and that's not something that can really be automated. Again, the question here was about automating this process of doing a release. So everything i am bringing up is in relation to that point. So from one POV there are 2 parts to releasing: 1. the actual release (tagging, publishing artifacts, publishing docs, etc) 2. various announcements (blog, email, twitter, etc) This "automated release job" people keep bringing up can really only do some of these tasks. The "problem" is that those are tasks we have already "automated" in Gradle itself - having an actual CI job to do the release really isn't buying us anything. 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. > I think we agree on the principles. We just need to have a viable > 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. 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? > In isolation 5.2 is not what we should be recommending to use - once 5.3 goes Final for sure. 5.2 -> 5.3 does have a minor hitch in this though in that it also represents a bump in JPA version. Which means that a user is not going to be able to simply drop 5.3 on top of 5.2 in a container (EE, Spring, etc) written to work with JPA 2.1. But even given that, I still think we are only going to do a limited number of additional 5.2 releases, stopping once 5.3 becomes stable. The real question is who is going to handle: 1. identifying what should get ported from 5.3/master to 5.2 2. performing the needed back ports 3. performing the release(s) Because the longer y'all want 5.2 releases to continue, the more help we are going to need _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
