Hi, If this is to block next release, then I will go for a 2.14 although I think that this numbering makes people think JMeter is only releasing minor fixes and think they don't have to upgrade.
Please sebb, can you give your final thought ? thankd Regards Philippe On Monday, January 25, 2016, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > Hello, > Regarding API Changes, I think the following changes are breaking > API/Plans (in the sense of JMeter): > > - In RandomTimer class, protected instance timer has been replaced by > getTimer() protected method, this is related to Bug 58100 > <http://bz.apache.org/bugzilla/show_bug.cgi?id=58100>. This may impact > 3rd party plugins. > - org.apache.jmeter.gui.util.ButtonPanel has been removed, if you use > it in your 3rd party plugin or custom development ensure you update your > code. See Bug 58687 > <http://bz.apache.org/bugzilla/show_bug.cgi?id=58687> > - WebService(SOAP) Request and HTML Parameter Mask which were > deprecated in 2.13 version, have now been removed following our deprecation > strategy > - org.apache.jmeter.protocol.http.visualizers.RequestViewHTTP.getQueryMap > signature has changed, if you use it ensure you update your code. See Bug > 58845 <http://bz.apache.org/bugzilla/show_bug.cgi?id=58845> > > > And switching to 3.0 would allow us to be more aggressive in some changes: > > - Since version 3.0, you can use Nashorn Engine (default javascript > engine is Rhino) under Java8 for Elements that use Javascript Engine > (__javaScript, IfController). If you want to use it, use property > javascript.use_rhino=false, see Bug 58406 > <http://bz.apache.org/bugzilla/show_bug.cgi?id=58406>. Note in future > versions, we will switch to Nashorn by default, so users are encouraged to > report any issue related to broken code when using Nashorn instead of > Rhino. => Switch to use_rhino=true > > > Even if we did similar changes in previous versions and did not respect > the versioning system, I think we should do it starting from now. > > Regards > > On Sun, Jan 24, 2016 at 1:38 PM, sebb <seb...@gmail.com > <javascript:_e(%7B%7D,'cvml','seb...@gmail.com');>> wrote: > >> On 24 January 2016 at 11:30, Felix Schumacher >> <felix.schumac...@internetallee.de >> <javascript:_e(%7B%7D,'cvml','felix.schumac...@internetallee.de');>> >> wrote: >> > Am 14.01.2016 um 15:16 schrieb Philippe Mouawad: >> >> >> >> Hi all, >> >> Can we go for a 3.0 or do we need to discuss it more or eventually run >> a >> >> vote on this ? >> > >> > I think there are two discussions in this thread. The first one was >> about >> > using semver for our versioning scheme. That scheme seemed to be >> accepted by >> > everyone. >> > >> > The other point was about the release number. >> > >> > The reasons that were brought up for a version 3.0 where of two kinds. >> > >> > 1. marketing (making it clear, that the jmeter from today is quite >> > different from the jmeter from years ago.) >> > >> > 2. semver. Here it wasn't clear, whether the changes in jmeter from the >> > last version where sufficient to call for a major release. >> > >> > I have run jpapicmp (https://siom79.github.io/japicmp/) comparing the >> last >> > three releases (including the next) and the tool reported major api >> changes >> > in all of them. So while a 3.0 would be valid for semver, it would have >> been >> > for the last two versions, too. >> > >> > I am still OK with going for semver for the versioning, but we might >> have to >> > discuss how we want to measure the api changes, so that we don't need to >> > discuss version numbers in the future. >> > >> > I am OK with a 3.0 considering the output of japicmp showed breaking api >> > changes, which would result in a new major release number. >> >> Breaking API changes shown by japicmp have very little bearing on >> whether JMeter users are affected. >> JMeter users are only likely to be affected by behaviourial changes. >> >> Even plugin writers are unlikely to be affected by the majority of API >> changes shown by japicmp. >> >> For example, not all public classes and methods are intended for use >> by plugin writers. >> >> The output of a tool such as japicmp is not particularly useful >> witthout proper analysis of the results. >> This would be true even of low-level library jars, as classes often >> have to be made public or protected even though they are not intended >> as part of the public API. >> >> Sorry, but I'm not sure that the analysis is much use in the case of >> JMeter. >> >> > Regards, >> > Felix >> > >> > >> >> >> >> Thanks >> >> Regards >> >> >> >> On Wed, Jan 13, 2016 at 10:18 PM, Antonio Gomes Rodrigues >> >> <ra0...@gmail.com <javascript:_e(%7B%7D,'cvml','ra0...@gmail.com');>> >> >> wrote: >> >> >> >>> Hi >> >>> >> >>> 2016-01-13 21:43 GMT+01:00 Philippe Mouawad < >> philippe.moua...@gmail.com >> <javascript:_e(%7B%7D,'cvml','philippe.moua...@gmail.com');>>: >> >>> >> >>>> On Wed, Jan 13, 2016 at 5:28 PM, Antonio Gomes Rodrigues < >> >>> >> >>> ra0...@gmail.com <javascript:_e(%7B%7D,'cvml','ra0...@gmail.com');> >> >>>> >> >>>> wrote: >> >>>> >> >>>>> Hi, >> >>>>> >> >>>>> My opinion >> >>>>> >> >>>>> I think it's a good idea to rename to 3.0 the next release, because: >> >>>>> Old release of JMeter have bad reputation (complex to use, bad >> >>>> >> >>>> performance, >> >>>>> >> >>>>> etc.) to people >> >>>>> People think that JMeter evolve slowly (I have even heard it from an >> >>>> >> >>>> Apache >> >>>>> >> >>>>> (not JMeter) commiter >> >>>>> Same reason than Milamber >> >>>>> >> >>>>> Remove old things (HC3.1 support, etc.) is great to because each >> time I >> >>>>> show JMeter to someone, he is afraid by the GUI >> >>>>> >> >>>>> Remove some listener is great to (the two proposed by Philippe >> Mouawad) >> >>>> >> >>>> and >> >>>>> >> >>>>> maybe other (I think about Monitor Results, >> >>>> >> >>>> +1 I think there are now better ways to do this and jmeter-plugins >> has 1 >> >>>> >> >>>> >> >>>>> Graph Results, >> >>>> >> >>>> +0, It can be useful in Debugging maybe >> >>>> >> >>>> >> >>>>> Assertion Results >> >>>>> >> >>>> I prefer your idea of debug listener than removal, because from >> >>>> Stackoverflow questions, I think this one is used >> >>>> >> >>>>> About listener I think it will be great to brain storming about them >> >>>>> because I think: >> >>>>> they are not modern >> >>>>> it misses some very interesting/important (some are present in >> JMeter >> >>>>> plugins) while JMeter have some very few helpfull >> >>>>> >> >>>> I tend to think that new report dashboard feature answers this. As >> we do >> >>> >> >>> no >> >>>> >> >>>> favor GUI testing, I am not sure we should enhance this with. >> >>>> For live graphing, we should I think enhance BackendLIstener with a >> JDBC >> >>>> persister at least. >> >>>> >> >>> I think too >> >>> >> >>> My complete opinion >> >>> Have the new report dashboard feature to have a complete report at the >> >>> end >> >>> of the load test >> >>> Have BackendLIstener to live graphing. Have a great live graphing >> allow >> >>> to >> >>> check the load test and stop/modify it if it's necessary (bad >> >>> configuration, bad data, etc.). It's usefull too for some test (for >> >>> example >> >>> chekc in live the result of a chaos monkey) >> >>> Only keep a few listeners in JMeter core (deprecate it and remove it) >> >>> Install JMeter Plugins to have more listener if we want to display >> >>> graphic >> >>> in JMeter >> >>> >> >>> >> >>> For the moment I have not test report dashboard feature but the >> >>> screenshot >> >>> I have seen are great. I will check them asap to check if something is >> >>> missing >> >>> >> >>> About BackendLIstener I have already test it and it's great. Maybe it >> >>> need >> >>> some GUI improvement and new supported backend (ElasticSearch, >> database) >> >>> >> >>> >> >>>> >> >>>>> I think it will be great to separate the listener in two parts: >> >>>>> >> >>>> Nice idea. >> >>>> >> >>>> >> >>>>> listener (all the interesting listener (Aggregate Graph, Response >> Time >> >>>>> Graph, etc.) >> >>>>> debug listener (Assertion Results, JSR223 Listener, etc.) >> >>>>> >> >>>>> It will be great to have project which regroup jmx files + results + >> >>> >> >>> data >> >>>>> >> >>>>> files like commercial tools (a zip file is sufficient) >> >>>>> >> >>>> Can you clarify this ? >> >>>> >> >>> Instead having one or more JMX files + data files (csv) + result load >> >>> test >> >>> files (csv, etc.) I think it will be better to have a single file >> which >> >>> contains all these files. >> >>> Or two files (one for the load scripts + data and the other for the >> >>> results >> >>> files) >> >>> >> >>> It will allow to easily send to a collegue the complete script with >> all >> >>> necessary files (csv, etc.) >> >>> The same to send the result of a load test >> >>> >> >>> >> >>> >> >>>>> It will be great to have 2 modes to hide some sampler/listener/etc. >> >>>>> One for newcomer and another for expert. >> >>>>> It will allow to don't scary newcomers the first time he launch >> JMeter >> >>>>> >> >>>> I like this idea, knowing that we have this property that we could >> use: >> >>>> #jmeter.expertMode=true >> >>>> >> >>>>> Or have one mode by technology tested (http, database, etc.) + >> expert >> >>>> >> >>>> mode >> >>>>> >> >>>>> will all >> >>>>> >> >>>>> Maybe remove some timer (I don't know is they are all used) >> >>>>> >> >>>> I think that all of them have their use but maybe put some only in >> >>>> expert >> >>>> mode. >> >>>> >> >>>> Another field of deprecation is maybe the BSF elements that seem to >> me >> >>>> better replaced by JSR223 elements. >> >>>> >> >>> +1 >> >>> >> >>>> Anyway thanks for all those ideas. >> >>>> >> >>>>> Antonio >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> 2016-01-08 0:48 GMT+01:00 Milamber <milam...@apache.org >> <javascript:_e(%7B%7D,'cvml','milam...@apache.org');>>: >> >>>>> >> >>>>>> Hello, >> >>>>>> >> >>>>>> For me, the jump to 3.0 must be done for next version. >> >>>>>> >> >>>>>> >> >>>>>> Remember: JMeter 2.0.0 was release in 2004, so 12 years ago and 23 >> >>>>>> versions have been release since! >> >>>>>> >> >>>>>> A lot of works since 2004 on the user interface (the toolbar, >> sampler >> >>>>>> forms, graphical listener, etc.) >> >>>>>> >> >>>>>> A lot of works under the woods, to improve the JMeter internal >> >>>>>> performance, the samplers like HTTP request (default HC4), the >> >>> >> >>> parallel >> >>>>>> >> >>>>>> resource download, etc) >> >>>>>> >> >>>>>> A lot of works to improve the user experience (like the Regexp >> >>> >> >>> tester, >> >>>>> >> >>>>> the >> >>>>>> >> >>>>>> templates box, the search on the JMeter tree, log pane, OS >> >>> >> >>> integration >> >>>>> >> >>>>> for >> >>>>>> >> >>>>>> copy/paste, POST body for WS request, etc.) >> >>>>>> >> >>>>>> Recently, a lot of works on the website to refresh the design (and >> >>>> >> >>>> logo) >> >>>>>> >> >>>>>> (a lot of this changes will publish on the next release) >> >>>>>> >> >>>>>> IMHO, the bump to JMeter 3.0, exceptionally can not only based on >> the >> >>>> >> >>>> new >> >>>>>> >> >>>>>> behaviors since the previous version (N-1) or API changes, but we >> >>> >> >>> need >> >>>> >> >>>> to >> >>>>>> >> >>>>>> consider the works of all developers since 2004. (and after change >> >>> >> >>> to a >> >>>>> >> >>>>> new >> >>>>>> >> >>>>>> number rules) >> >>>>>> >> >>>>>> >> >>>>>> Apache JMeter isn't comparable with project like Commons or >> >>> >> >>> HTTPClient >> >>>> >> >>>> on >> >>>>>> >> >>>>>> the versions rules. Commons/HC are mainly use as a framework inside >> >>>>> >> >>>>> another >> >>>>>> >> >>>>>> software (like JMeter). JMeter is mainly use a as end user >> software, >> >>>> >> >>>> the >> >>>>>> >> >>>>>> API (break/don't break) isn't the alone criteria to change the >> >>> >> >>> versions >> >>>>>> >> >>>>>> number. The UI and the engine must be consider to the next release >> >>>>> >> >>>>> number. >> >>>>>> >> >>>>>> Last reason to change : The users may be confused with a 2.x >> version >> >>>> >> >>>> from >> >>>>>> >> >>>>>> 2004 (works only with Java 1.4, some jvm args are now >> incompatibles) >> >>>> >> >>>> and >> >>>>> >> >>>>> a >> >>>>>> >> >>>>>> 2.14 version which require Java 7. >> >>>>>> >> >>>>>> >> >>>>>> Milamber >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On 05/01/2016 11:01, sebb wrote: >> >>>>>> >> >>>>>>> On 4 January 2016 at 18:23, Philippe Mouawad < >> >>>>> >> >>>>> philippe.moua...@gmail.com >> <javascript:_e(%7B%7D,'cvml','philippe.moua...@gmail.com');>> >> >>>>>>> >> >>>>>>> wrote: >> >>>>>>> >> >>>>>>>> First Happy new year 2016 ! >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Mon, Jan 4, 2016 at 4:26 PM, sebb <seb...@gmail.com >> <javascript:_e(%7B%7D,'cvml','seb...@gmail.com');>> wrote: >> >>>>>>>> >> >>>>>>>> JMeter does not have a formal policy for major/minor version >> >>> >> >>> release >> >>>>>>>>> >> >>>>>>>>> updates. >> >>>>>>>>> However historically major veresion changes have been associated >> >>>> >> >>>> with >> >>>>>>>>> >> >>>>>>>>> major changes. >> >>>>>>>>> >> >>>>>>>>> I am proposing to follow what seems to become a standard in >> >>>> >> >>>> versioning >> >>>>>>>> >> >>>>>>>> refering to a proposal from a scientist working on the subject. >> >>>>>>>> >> >>>>>>> http://semver.org/ says: >> >>>>>>> >> >>>>>>> Increment the MAJOR version when you make incompatible API >> changes, >> >>>>>>> >> >>>>>>> We are not doing that. >> >>>>>>> >> >>>>>>> Also other ASF projects such as Commons and HttpClient require >> major >> >>>>>>>>> >> >>>>>>>>> version bumps when removing deprecated code. >> >>>>>>>>> >> >>>>>>>>> So isn't this what we are doing as we dropped 4 classes >> >>>> >> >>>> corresponding >> >>>>> >> >>>>> to >> >>>>>>>> >> >>>>>>>> deprecated elements. And we will deprecate some more. >> >>>>>>>> But the main idea behind this is that next version contains major >> >>>>>>>> features >> >>>>>>>> which I think deserve this change. >> >>>>>>>> >> >>>>>>> What features are you referring to? >> >>>>>>> >> >>>>>>> >> >>>>>>>> I don't think the proposed changes warrant a major version bump. >> >>>>>>>>> >> >>>>>>>>> I don't understand, but if we don't come to an agreement I >> propose >> >>>> >> >>>> to >> >>>>>>>> >> >>>>>>>> run a >> >>>>>>>> vote on this although it would be better to avoid it. >> >>>>>>>> >> >>>>>>>> On 3 January 2016 at 15:36, Milamber <milam...@apache.org >> <javascript:_e(%7B%7D,'cvml','milam...@apache.org');>> wrote: >> >>>>>>>>>> >> >>>>>>>>>> I agree with a new release with a new version number system, >> and >> >>>> >> >>>> with >> >>>>>>>>>> >> >>>>>>>>>> the >> >>>>>>>>>> next release to become 3.0. >> >>>>>>>>>> >> >>>>>>>>>> Before the next release, I would like add the HiDPI (high >> >>>> >> >>>> definition >> >>>>>>>>> >> >>>>>>>>> screen) >> >>>>>>>>> >> >>>>>>>>>> for JMeter (for Linux Gnome/GTK and Windows). Currently I works >> >>> >> >>> on >> >>>>>>>>>> >> >>>>>>>>>> this. >> >>>>>>>>>> (my new computer have a 3200x1800 resolution on a 13' screen, >> >>>> >> >>>> JMeter >> >>>>> >> >>>>> is >> >>>>>>>>> >> >>>>>>>>> very >> >>>>>>>>> >> >>>>>>>>>> small with the CrossPlatform Swing UI) >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On 03/01/2016 15:08, Philippe Mouawad wrote: >> >>>>>>>>>> >> >>>>>>>>>>> Hi Felix, >> >>>>>>>>>>> Thanks for answer. >> >>>>>>>>>>> I don't think it will be a long hold on the new release, for >> me >> >>> >> >>> we >> >>>>>>>>>>> >> >>>>>>>>>>> have >> >>>>>>>>>>> these remaining points: >> >>>>>>>>>>> >> >>>>>>>>>>> - Integrate HTTPCLIENT 4.5.2 to fix >> >>>>>>>>>>> - 58583 < >> >>>> >> >>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=58583> >> >>>>>>>>>>> >> >>>>>>>>>>> - 57319 >> >>>>>>>>>>> - Finalize tests >> >>>>>>>>>>> - 57804 => Waiting confirmation from Rainer or any other >> >>>> >> >>>> member >> >>>>>>>>>>> >> >>>>>>>>>>> of >> >>>>>>>>>>> >> >>>>>>>>>> the >> >>>>>>>>>> team >> >>>>>>>>>>> >> >>>>>>>>>>> - Deprecation: >> >>>>>>>>>>> - 58791 => I will do it >> >>>>>>>>>>> - Not mandatory but would be nice: >> >>>>>>>>>>> - 58793 >> >>>>>>>>>>> - 58790 >> >>>>>>>>>>> - 58792 => I will try to stat it >> >>>>>>>>>>> - 58794 => I will start a discussion on this >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> That's all for me, but if you see other things feel free to >> add >> >>>> >> >>>> it. >> >>>>>>>>>>> >> >>>>>>>>>>> Thanks >> >>>>>>>>>>> >> >>>>>>>>>>> Regards >> >>>>>>>>>>> >> >>>>>>>>>>> Philippe M. >> >>>>>>>>>>> >> >>>>>>>>>>> @philmdot >> >>>>>>>>>>> >> >>>>>>>>>>> On Sun, Jan 3, 2016 at 3:37 PM, Felix Schumacher < >> >>>>>>>>>>> felix.schumac...@internetallee.de >> <javascript:_e(%7B%7D,'cvml','felix.schumac...@internetallee.de');>> >> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> Am 01.01.2016 um 19:14 schrieb Philippe Mouawad: >> >>>>>>>>>>>> >> >>>>>>>>>>>> Hi, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Happy new year to the whole team. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Any news on this ? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I have nothing against a 3.0, but I would not like it, if >> the >> >>>>> >> >>>>> "big" >> >>>>>>>>>>>> >> >>>>>>>>>>>> version change would lead to a long hold up of a new release. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Regards, >> >>>>>>>>>>>> Felix >> >>>>>>>>>>>> >> >>>>>>>>>>>> Thanks >> >>>>>>>>>>>> >> >>>>>>>>>>>>> On Tue, Dec 29, 2015 at 5:19 PM, Philippe Mouawad < >> >>>>>>>>>>>>> philippe.moua...@gmail.com >> <javascript:_e(%7B%7D,'cvml','philippe.moua...@gmail.com');>> wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Hi, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>>> Following my proposals to deprecate a certain number of >> >>>> >> >>>> elements >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> that >> >>>>>>>>>>>>>> were >> >>>>>>>>>>>>>> approved by 2 commiters and knowing that we have some >> >>> >> >>> important >> >>>>> >> >>>>> new >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> features in this release, I propose to name next version >> 3.0 >> >>>>>>>>>>>>>> instead >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>> of >> >>>>>>>>>> >> >>>>>>>>>> 2.14. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> It would be the occasion to make a big cleanup in all >> >>> >> >>> "oldies" >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> elements >> >>>>>>>>>> >> >>>>>>>>>> and maybe be even more aggressive in the deprecations/removals. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> And starting from there change our release naming to follow >> >>>> >> >>>> this: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> - http://semver.org/ >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> This has been mentioned by this thread and I think it's a >> >>> >> >>> good >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> idea: >> >>>>>>>>>>>>>> - >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>> >> >>> >> http://mail-archives.apache.org/mod_mbox/jmeter-dev/201411.mbox/%3CCAFJ7uesG%2BsKiQh_wQ5_iLp%3DJ%2BtSiG5fQ%3D7Pp1CvbJ1kncXo%2B%3Dg%40mail.gmail.com%3E >> >>>>>>>>>> >> >>>>>>>>>> I think in the developers thinking our current naming is not >> >>> >> >>> great, >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> cause >> >>>>>>>>>>>>>> one can think every "major" release we do is a Minor >> release. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>> Regards >> >>>>>>>>>>>>>> Philippe M. >> >>>>>>>>>>>>>> @philmdot >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Cordialement. >> >>>>>>>> Philippe Mouawad. >> >>>>>>>> >> >>>>>>> . >> >>>>>>> >> >>>>>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Cordialement. >> >>>> Philippe Mouawad. >> >>>> >> >> >> >> >> > >> > > > > -- > Cordialement. > Philippe Mouawad. > > > -- Cordialement. Philippe Mouawad.
