On Tue, Feb 9, 2016 at 8:01 PM, sebb <seb...@gmail.com> wrote: > On 8 February 2016 at 11:58, Philippe Mouawad > <philippe.moua...@gmail.com> 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. > > > > It's not clear to me what you are asking here. > > Are you asking: > - if the next version should be 3.0 rather than 2.14? > Yes
> or > - are we ready to release 3.0? > No > > As to the former, I still think it's unnecessary to bump to 3.0. > There are some disadvantages, as a major version bump implies > potentially major upheavals or even breakages (think of certain OS > system version bumps). > However since the version discussion started there have been quite a > few more improvements, and there are some minor incompatibilities, so > I will abstain on this question. > Thanks > > As to are we ready, I don't think we are there quite yet. > The new dashboard still needs some work. > I see you are creating bugzillas now. Ok for me > There are issues with the new version of HC. > Yes anyway, we are still waiting for 4.5.2 release. As you are a HTTPClient commiter and PMC member, do you know when a release is planned ? As of remaining issues, as far as I can tell , here are the remaining issues: - https://bz.apache.org/bugzilla/show_bug.cgi?id=58807 <https://bz.apache.org/bugzilla/show_bug.cgi?id=58807> => Patch available , waiting for commit - https://bz.apache.org/bugzilla/show_bug.cgi?id=58583 <https://bz.apache.org/bugzilla/show_bug.cgi?id=58583> => Just Needs HC4.5.2+ Uncomment code - https://bz.apache.org/bugzilla/show_bug.cgi?id=57804 => Waiting for Rainer confirmation + my comment to check: ------------------------------------------------------------------------------------------------------------------------------------------------ Beside this, I notice a change in the logs in the NoClientCert test case attached between 2.13 and 2.14, I cannot tell if it's a bug or regular. If you compare nohup-2.14-pre-commit-1721771-no-client-cert.log with nohup-2.13-no-client-cert.log. With 2.13 I see only 1 time => *** ClientHello, TLSv1 With 2.14 I see 4 times => *** ClientHello, TLSv1, but preceded the 3 last times with => %% Try resuming [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA] from port 2571 ------------------------------------------------------------------------------------------------------------------------------------------------ - Ignore policy in Cookie => Just needs HC4.5.2 - https://bz.apache.org/bugzilla/show_bug.cgi?id=58950 => Just Needs HC4.5.2 and potentially there is another issue <https://bz.apache.org/bugzilla/show_bug.cgi?id=58950> Do you see anything else ? > > Regards > > > > Philippe > > > > On Tue, Feb 2, 2016 at 11:48 PM, Philippe Mouawad < > > philippe.moua...@gmail.com> 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 < > 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> wrote: > >>> > >>>> On 24 January 2016 at 11:30, Felix Schumacher > >>>> <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> > >>>> >> wrote: > >>>> >> > >>>> >>> Hi > >>>> >>> > >>>> >>> 2016-01-13 21:43 GMT+01:00 Philippe Mouawad < > >>>> philippe.moua...@gmail.com>: > >>>> >>> > >>>> >>>> On Wed, Jan 13, 2016 at 5:28 PM, Antonio Gomes Rodrigues < > >>>> >>> > >>>> >>> 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>: > >>>> >>>>> > >>>> >>>>>> 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> > >>>> >>>>>>> > >>>> >>>>>>> wrote: > >>>> >>>>>>> > >>>> >>>>>>>> First Happy new year 2016 ! > >>>> >>>>>>>> > >>>> >>>>>>>> > >>>> >>>>>>>> > >>>> >>>>>>>> On Mon, Jan 4, 2016 at 4:26 PM, sebb <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> > >>>> 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> 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> 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. > -- Cordialement. Philippe Mouawad.
