jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Identify somehow public API
Date Mon, 03 Apr 2017 19:17:05 GMT
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 <apc4@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message