Re: Deprecating API signatures referring to Guava in 1.10

2019-12-10 Thread Julian Reschke
On 10.12.2019 08:44, Angela Schreiber wrote: Hi Marcel That sounds reasonable to me. Kind regards Angela The number of commits to be backported to align with the pre-Guava deprecation state is: 3. The number of commits to deprecate the Guava APIs is: 7 I don't understand why we would want

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-09 Thread Angela Schreiber
Hi Marcel That sounds reasonable to me. Kind regards Angela From: Marcel Reutegger Sent: Monday, December 9, 2019 2:15 PM To: oak-dev@jackrabbit.apache.org Subject: Re: Deprecating API signatures referring to Guava in 1.10 Hi, On 06.12.19, 14:07, "J

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-09 Thread Julian Reschke
On 09.12.2019 14:47, Julian Reschke wrote: ... I'll have a look at what *exact* changes would be needed for b)... ... So I checked, and it seems that we have exactly three "precondition" changes that would need to be backported: OAK-8108: Move LazyValue from oak-core to oak-commons Export

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-09 Thread Julian Reschke
On 09.12.2019 14:15, Marcel Reutegger wrote: Hi, On 06.12.19, 14:07, "Julian Reschke" wrote: once we do a stable release from trunk with the removal (say, 1.26), there would be no officially supported Oak release which deprecates the API. That is, 1.10.* (and earlier) would contain the old

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-09 Thread Marcel Reutegger
Hi, On 06.12.19, 14:07, "Julian Reschke" wrote: > once we do a stable release from trunk with the removal (say, 1.26), > there would be no officially supported Oak release which deprecates the > API. That is, 1.10.* (and earlier) would contain the old API (and not > deprecate it), 1.26.0 (and

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-06 Thread Manfred Baedke
+1 On 12/6/2019 2:07 PM, Julian Reschke wrote: That is, 1.10.* (and earlier) would contain the old API (and not deprecate it), 1.26.0 (and later) would only contain the new API. I don't believe that's acceptable.

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-06 Thread Julian Reschke
On 05.12.2019 16:00, Angela Schreiber wrote: Hi Julian Sorry, but I still don't get why we have to back port the deprecation plus replacements to 1.10. If we remove the API in Oak 1.26 there are at a whole bunch of official releases between the deprecation/replacement and the release where

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-05 Thread Angela Schreiber
Hi Julian From: Julian Reschke Sent: Thursday, December 5, 2019 5:39 PM To: Angela Schreiber ; oak-dev@jackrabbit.apache.org Subject: Re: Deprecating API signatures referring to Guava in 1.10 On 05.12.2019 16:49, Angela Schreiber wrote: > Hi Julian > >

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-05 Thread Julian Reschke
On 05.12.2019 16:49, Angela Schreiber wrote: Hi Julian I can't speak for Adobe AEM product management (the product you are referring to) and their release planning for the near future. But I would be surprised if there wasn't a way forward handling potential upgrade issues when it comes to the

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-05 Thread Angela Schreiber
Reschke Sent: Thursday, December 5, 2019 4:12 PM To: Angela Schreiber ; oak-dev@jackrabbit.apache.org Subject: Re: Deprecating API signatures referring to Guava in 1.10 On 05.12.2019 16:00, Angela Schreiber wrote: > Hi Julian > > Sorry, but I still don't get why we have to back port the de

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-05 Thread Julian Reschke
On 05.12.2019 16:00, Angela Schreiber wrote: Hi Julian Sorry, but I still don't get why we have to back port the deprecation plus replacements to 1.10. If we remove the API in Oak 1.26 there are at a whole bunch of official releases between the deprecation/replacement and the release where the

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-05 Thread Angela Schreiber
in different branches that don't exactly match. Kind regards Angela From: Julian Reschke Sent: Thursday, December 5, 2019 2:55 PM To: oak-dev@jackrabbit.apache.org ; Angela Schreiber Subject: Re: Deprecating API signatures referring to Guava in 1.10 On 05.12.2019 13

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-05 Thread Julian Reschke
On 05.12.2019 13:41, Angela Schreiber wrote: Hi Julian Maybe you could elaborate a bit more about the reasoning of backporting the deprecated API signatures using Guava 1.10? The reason for the deprecation was the fact that we want to make breaking changes, right? And this is the kind of

Re: Deprecating API signatures referring to Guava in 1.10

2019-12-05 Thread Angela Schreiber
To: oak-dev@jackrabbit.apache.org Subject: Deprecating API signatures referring to Guava in 1.10 Hi there, see <https://issues.apache.org/jira/browse/OAK-7182>. In trunk, we now have deprecated all API signatures that used Guava objects. I'd like to gradually backport these changes t

Deprecating API signatures referring to Guava in 1.10

2019-12-05 Thread Julian Reschke
Hi there, see . In trunk, we now have deprecated all API signatures that used Guava objects. I'd like to gradually backport these changes to 1.10, but this will be tricky due to the semantic versioning of the APIs. For instance, changes in