On 8 February 2016 at 11:58, 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. >
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? or - are we ready to release 3.0? 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. As to are we ready, I don't think we are there quite yet. The new dashboard still needs some work. There are issues with the new version of HC. > 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.
