Since JMeter 2.9 there was no compatibility problems for jp@gc with new releases of JMeter. I don't see the issue and need to make any automated check for that. JMeter releases have very detailed changelog and I have time to test compatibility before JMeter releases.
>From my experience, Ultimate Thread Group is rarely needed. Most of the times stock Thread Group with proper settings is enough with one exception of stepping profile. Andrey Pokhilko On 05/19/2015 01:48 PM, Philippe Mouawad wrote: > So I think jmeter-plugins is favored :) as we say "is THE companion". > > Regarding tests , I think JP has improved its tests and we try to be > retro-compatible and document any change for 3rd parties. > sebb is really keen on maintaining this retro compat ;) > > But other automated ideas are welcome. > > Regards > > On Tuesday, May 19, 2015, Philippe Mouawad <[email protected]> > wrote: > >> Hi, >> In 2.13 documentatio was updated: >> >> - http://jmeter.apache.org/usermanual/boss.html >> >> Regards >> >> On Tuesday, May 19, 2015, Vladimir Sitnikov <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>>> We cannot favour one 3rd party plugin over another >>> We can/should favour all. >>> >>> JMeter's front page screams at you with "Highly Extensible core", >>> while it does not justify the claims. >>> It would be much better to put references to the relevant sections of >>> documentations and/or wiki. >>> >>> "Highly extensible" claim with zero useful extensions is of no use. >>> We all know there are good extensions, why don't we list some, so >>> users could easier get feel of the possibilities? >>> >>> Current JMeter wiki does reference lots of external sources: >>> http://wiki.apache.org/jmeter/ >>> >>> Here's what I got right from that http://wiki.apache.org/jmeter: >>> http://wiki.apache.org/jmeter/JMeterMavenPlugin >>> http://wiki.apache.org/jmeter/MysqlCollectorPlugin >>> http://wiki.apache.org/jmeter/MonitoringServers >>> http://wiki.apache.org/jmeter/LogAnalysis >>> etc. >>> >>> In other words, current JMeter's documentation favours some of the >>> plugins over another. >>> >>> >>>> We don't test and cannot recommend particular 3rd party plugins. >>> At least Philippe, Andrey, and myself use "jmeter plugins" on a regular >>> basis. >>> I have no idea if JMeter release procedure includes integration >>> testing with jmeter-plugins, but I believe JMeter should at lest >>> verify that "new JMeter version does not break plugins". >>> Obviously, JMeter cannot test against all the possible plugins, but it >>> is a good idea to test for compatibility with well-known plugins. >>> >>> I think j-p provides much higher level of quality than "mentioned in >>> JMeter's documentation >>> http://wiki.apache.org/jmeter/MysqlCollectorPlugin";, so the reference >>> to j-p in the JMeter's documentation is well deserved. >>> >>> Here's what PostgreSQL does in similar case: >>> 1) The list of "external projects" right in the PostgreSQL core >>> documentation: >>> http://www.postgresql.org/docs/9.4/interactive/external-projects.html >>> "PostgreSQL is a complex software project, and managing the project is >>> difficult. We have found that many enhancements to PostgreSQL can be >>> more efficiently developed separately from the core project." >>> >>> 2) The list with _lots_ of external plugins/articles right in the >>> official wiki: >>> https://wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL >>> , https://wiki.postgresql.org/wiki/Performance_Optimization >>> >>> Vladimir >>> >> >> -- >> Cordialement. >> Philippe Mouawad. >> >> >> >>
