Hi Julian But why do we have to align Oak 1.10 with trunk now that we have stable release on regular basis instead of releasing only once a year?
IMO it would be better and a lot less risky to push for updating to a more recent version of Oak that already includes the reeplacements than back porting the huge number of API changes we made over the last couple of years. Kind regards Angela ________________________________ From: Julian Reschke <[email protected]> Sent: Thursday, December 5, 2019 2:38 PM To: [email protected] <[email protected]>; Angela Schreiber <[email protected]> Subject: Re: Intent to backport to 1.10: OAK-8018 On 05.12.2019 13:51, Angela Schreiber wrote: > Hi Julian > > This changes with OAK-8018 modified public API as far as I can see and I > vaguely remember that we concluded in the past that we want to avoid back > porting anything that is not a critical bug and be particularly careful not > to back port API changes. Backporting the API change is the whole point here; it's a prerequisite to align 1.10's API with the one in trunk. I recall that we discussed backports a few years ago, but I actually do not recall the concrete conclusion (do you have a pointer?). In this case, it's obviously a conflict between backporting minor changes and being able to backport something that (IMHO) is needed in 1.10. We can't do the latter without doing the former. We *did* actually discuss backporting API changes in the past, and the conclusion IMHO was: do it only if you understand the consequences with respect to public package version numbers. That's what I'm trying to do here. See also <http://jackrabbit.apache.org/jcr/creating-releases.html#Appendix_E:_Version_Changes>. > I would appreciate if you could wait with that back port until we reached a > consensus on the broader goal as you announced in the previous thread > "Deprecating API signatures referring to Guava in 1.10". Looking forward to your feedback on that one. Best regards, Julian
