On Thu, Jan 25, 2018 at 3:55 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
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".
I'm talking about the blog post itself.
I mean that for micro releases, the ORM blog announcement is as this one:
http://in.relation.to/2018/01/10/hibernate-orm-5111-final-release/ or this
one
http://in.relation.to/2017/10/19/hibernate-orm-5212-final-release/ for
quite a while now.
So it does not require as much work as what you put in the 5.3.0.Beta1 blog
post for instance.
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.
Well, it might be just me but I like to try to give a personal touch to the
announcements when I have the time to do it.
So when I don't, I mostly reuse the previous one but, otherwise, I like to
give a more "human" touch to the communication.
That's why I invested so much time in having an entirely automated release
process for the NoORM side (based on Davide's previous work for OGM, to be
fair) but not so much in the automated communication part.
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.
Yeah, that's why I quoted "stable".
For me, we can safely stop maintaining a back branch as soon as the new one
is consumable by the end users (i.e. application developers in our case).
By this, I mean:
- the obvious regressions have been fixed and the new version is usable in
most cases (it usually takes at least one micro)
- the integrators have done their work on integrating the new version - by
integrators, these days, I mostly mean Spring. I wouldn't put this
condition if they weren't reactive enough but they are.
I.e. we can now consider that the users can safely move to the new version.
They can do it or not, it's their business, but they don't have the obvious
excuse of not being able to do it.
As long as the new one is not consumable by the end users, I would continue
to maintain the back branch, be it a product branch or not.
--
Guillaume