On 8 June 2016 at 15:06, Steve Ebersole wrote:
> Well the reasoning was discussed on this list and everyone agreed :) It
> was part of a larger discussion about releases and maintaining maintenance
> branches. But if everyone, I am ok with doing CR (only) for minor releases.
>
> Part of the reas
So I think we all agree that a hybrid approach is a good think, but the
only drawback is that the release takes time and Steve is the only one in
charge to make this release.
Is it possible to have one more person that is allowed to initiate a
RC release?
The release burden should be shared.
Vlad
On Wed, Jun 8, 2016 at 9:20 AM Vlad Mihalcea
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 r
I think it's just about what our users expect from a Final release. If we
mark a release with the CR suffix, people will know this might have bugs
and they can help us identify them before we release the Final version.
If there is a backward incompatibility issue, we catch it in the CR release
and,
+1 for the hybrid approach if we feel we need minor release CRs.
On 06/08/2016 09:06 AM, Steve Ebersole wrote:
> 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.
>
__
Well the reasoning was discussed on this list and everyone agreed :) It
was part of a larger discussion about releases and maintaining maintenance
branches. But if everyone, I am ok with doing CR (only) for minor releases.
Part of the reasoning was that technically speaking a Final really ought
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
+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.
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 relea
