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 guarantee on backward compatibility I see 3 advantages: - Users know what is "public" API - We take care more thoroughly about it - It will kind of drive the creation of an API for JMeter Regards On Mon, Apr 3, 2017 at 9:15 AM, Andrey Pokhilko <a...@ya.ru> wrote: > 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 potential. > > Andrey Pokhilko > > On 03.04.2017 08:44, Philippe Mouawad wrote: > > Hello, > > I think it would be interesting to identify in code public API for users > > that would manipulate JMeter code through custom code (Groovy / > Javascript > > /Beanshell) and for plugin developers. > > > > This is to avoid breaking backWard compatibility and to allow us to make > > cleanups and evolution in a fast and safe way. > > > > > > I didn't find any existing tag to do that, maybe we could create a > javadoc > > or annotation to do that. > > > > We could then have it in javadocs and run backward cmpat checker. > > > > Thoughts ? > > > > Regards > > Philippe > > > > > > -- Cordialement. Philippe Mouawad.
