+1 for 3.0 On Mon, Feb 8, 2016 at 5:58 AM, Philippe Mouawad <[email protected] > wrote:
> Hello, > Status for now: > > For a 3.0: > > - Milamber (*) > - Antonio Gomes Rodrigues > - me (*) > > For a 2.14: > > - sebb (*) > > For a 3.0 if it does not holds next release for too long (this is not the > case, for now release 3.0 is blocked by release of HttpClient 4.5.2 and > this discussion): > > - Felix (*) > > (*) Binding as PMC member > > > Do I need to open a technical vote on this issue or can we go for a 3.0.0 ? > > I will wait 24 hours before starting this technical vote. > > > Regards > > Philippe > > On Tue, Feb 2, 2016 at 11:48 PM, Philippe Mouawad < > [email protected]> wrote: > > > 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 < > [email protected]> > > 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 <[email protected]> wrote: > >> > >>> On 24 January 2016 at 11:30, Felix Schumacher > >>> <[email protected]> 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 > >>> >> <[email protected]> > >>> >> wrote: > >>> >> > >>> >>> Hi > >>> >>> > >>> >>> 2016-01-13 21:43 GMT+01:00 Philippe Mouawad < > >>> [email protected]>: > >>> >>> > >>> >>>> On Wed, Jan 13, 2016 at 5:28 PM, Antonio Gomes Rodrigues < > >>> >>> > >>> >>> [email protected] > >>> >>>> > >>> >>>> 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 <[email protected]>: > >>> >>>>> > >>> >>>>>> 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 < > >>> >>>>> > >>> >>>>> [email protected]> > >>> >>>>>>> > >>> >>>>>>> wrote: > >>> >>>>>>> > >>> >>>>>>>> First Happy new year 2016 ! > >>> >>>>>>>> > >>> >>>>>>>> > >>> >>>>>>>> > >>> >>>>>>>> On Mon, Jan 4, 2016 at 4:26 PM, sebb <[email protected]> > 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 <[email protected]> > >>> 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 < > >>> >>>>>>>>>>> [email protected]> 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 < > >>> >>>>>>>>>>>>> [email protected]> 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. > > > > > > > > > > > -- > Cordialement. > Philippe Mouawad. > -- Thank you, Regards, NaveenKumar N Visit www.QAInsights.com and www.Testifications.com and www.MyTechCube.com
