Hi, I have seen the frustration from the Spring Data team trying to keep up with our code changes that break their integrations, and I was wondering if we should use some Release candidates prior to releasing a start of a branch, even if it's a minor one. This way, instead of 5.2.0, we could release 5.2.0.RC1 or something like that to mark it as an intermediary release that's aimed for early adopters/integrators. Do you think this is feasible or is there something to prevent us from doing this? Vlad _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Sanne, you just said it.. the reason you did not test with 5.2 before it was released is time. Me doing a CR release does not change that. The stuff that "bit you" in 5.2 was available for testing for well over a month prior to releasing 5.2. And it's not like 5.2 was released without discussion; heck we even pushed it back a few times to get a few extras in. All discussed on the dev list. On Wed, Jun 8, 2016 at 7:55 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > +1 > > I've also hit some incompatible API changes which I only figured out > too late (when attempting to upgrade Hibernate Search). > > I could have pre-tested snapshot builds but didn't have time for that > - and didn't expect 5.2 to be released without a Beta period, or I > would have made time for that. > > > On 8 June 2016 at 08:09, Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; wrote: > > Hi, > > > > I have seen the frustration from the Spring Data team trying to keep up > > with our code changes that break their integrations, > > and I was wondering if we should use some Release candidates prior to > > releasing a start of a branch, even if it's a minor one. > > This way, instead of 5.2.0, we could release 5.2.0.RC1 or something like > > that to mark it as an intermediary release that's aimed for early > > adopters/integrators. > > > > Do you think this is feasible or is there something to prevent us from > > doing this? > > > > Vlad > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

On Wed, Jun 8, 2016 at 9:20 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; wrote: > If there is a backward incompatibility issue, we catch it in the CR > release and, by the time we release Final, we know we got it fixed. > If I had to guess, this is what Spring Data devs are more interested in. We have been doing a lot of refactoring in 5.x. > So, with a CR, we just buy more time. Not only that we have OGM and > Search to provide feedback on the latest CR releases, but even the Spring > Data team tries to integrate our latest artifacts into their platform. > But see "buying more time" is not necessarily a good thing. Because really here that means allow the release to take more time: - allow it more bake time - obviously that's ok, within reason - more discussion - again ok, within bounds. For example, each and every one of the major changes in 5.2 was discussed in specific on dev channels as it was being designed and developed. Again, its all about moderation - more time to physically do releases - it takes me roughly half a day to do a release. Between running the release build, fighting Nexus, changing the website, announcing, etc. Those half days add up So let's be careful here. Go back to the original discussion. We used to, quite bluntly, waste a lot of time just doing release-y things. It sucks when I barely have time to dev as it is, and now I have to take some of that time and invest it back into release-y stuff. Many end-user applications will never try the CR releases, so they will > just go to Final versions which are more stable. > Exact same argument for SNAPSHOT :)

back to this then I vote that we also go for a hybrid approach to this where Final is an approximation of the "approved CR", likely with additional fixes.