Re: Identify somehow public API

2017-04-03 Thread Andrey Pokhilko
Hi, I don't support this, because it will limit extenders to much smaller API than they have now. Just because we hit couple of methods that caused issues with extensions, does not mean we should _control more_ what is used. Why limit the freedom? IMO benefits here much less than loss of extension

Re: [VOTE] Release JMeter 3.2 RC2

2017-04-03 Thread Antonio Gomes Rodrigues
Hi, Like Philippe [X] I do not support this release In my opinion, we need to deprecate this API in 3.2 release and remove it in 3.3 Antonio 2017-04-03 7:40 GMT+02:00 Philippe Mouawad : > Hello, > Thanks Milamber for your work on RM for this. > > Due to issue reported my vote is: > > [X] I do

Re: Identify somehow public API

2017-04-03 Thread Antonio Gomes Rodrigues
Hi, I don't think it's too controle more but to allow to deprecate them before remove them. It will allow to warn users that manipulate JMeter code through custom code (Groovy / Javascript /Beanshell) and for plugin developers. Antonio 2017-04-03 9:15 GMT+02:00 Andrey Pokhilko : > Hi, > > I don

Re: Identify somehow public API

2017-04-03 Thread Felix Schumacher
Am 3. April 2017 11:47:11 MESZ schrieb Antonio Gomes Rodrigues : >Hi, > >I don't think it's too controle more but to allow to deprecate them >before >remove them. I don't understand, of you are pro marking public api explicitly, or for deprecating public api that was never meant to be public a

Re: Identify somehow public API

2017-04-03 Thread sebb
On 3 April 2017 at 11:31, Felix Schumacher wrote: > > > Am 3. April 2017 11:47:11 MESZ schrieb Antonio Gomes Rodrigues > : >>Hi, >> >>I don't think it's too controle more but to allow to deprecate them >>before >>remove them. > > I don't understand, of you are pro marking public api explicitly, o

Re: Identify somehow public API

2017-04-03 Thread Philippe Mouawad
Hello Andrey, My idea is just to identify "Public API" for which backward compatibility is strict: - Deprecation is done in N+1 - Removal is done in N+2 And we try as much as possible to keep backward compatibility. Users are free to use other API (public classes) as today but won't have g

Re: [VOTE] Release JMeter 3.2 RC2

2017-04-03 Thread Milamber
Hello, I will cancel the RC2 vote and start a RC3 next Wednesday or Friday (after the re-introduction of the removed API. cc Philippe). Please continue your test about RC2 to find a lot of bugs before the RC3 ;-) Milamber On 03/04/2017 10:45, Antonio Gomes Rodrigues wrote: Hi, Like Philipp

Build failed in Jenkins: JMeter Windows #575

2017-04-03 Thread Apache Jenkins Server
See Changes: [pmouawad] Reintroduce old method in deprecated mode -- [...truncated 127.55 KB...] [jmeter] Tidying up ...@ Mon Apr 03 19:49:53 UTC 2017 (1491248993273

Re: [VOTE] Release JMeter 3.2 RC2

2017-04-03 Thread Philippe Mouawad
Thanks Milamber ! Maybe we should run this tool ( https://github.com/lvc/japi-compliance-checker) on JMeter 3.2 RC2 vs 3.1 to double check there are no other similar non identified issues. Regards On Mon, Apr 3, 2017 at 9:20 PM, Milamber wrote: > Hello, > > I will cancel the RC2 vote and start

Re: Identify somehow public API

2017-04-03 Thread Andrey Pokhilko
I simply see no problem here... JMeter as project is extremely careful with stability and compatibility, why change anything? Bugs happen for everyone and it's good that we caught them, not our users... Andrey Pokhilko On 03.04.2017 22:17, Philippe Mouawad wrote: > Hello Andrey, > My idea is just