Hi all, Can we go for a 3.0 or do we need to discuss it more or eventually run a vote on this ?
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.
