jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: Release a 3.0
Date Sun, 24 Jan 2016 11:30:41 GMT
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.

Regards,
  Felix

>
> Thanks
> Regards
>
> On Wed, Jan 13, 2016 at 10:18 PM, Antonio Gomes Rodrigues <ra0077@gmail.com>
> wrote:
>
>> Hi
>>
>> 2016-01-13 21:43 GMT+01:00 Philippe Mouawad <philippe.mouawad@gmail.com>:
>>
>>> On Wed, Jan 13, 2016 at 5:28 PM, Antonio Gomes Rodrigues <
>> ra0077@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 <milamber@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.mouawad@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> First Happy new year 2016 !
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 4, 2016 at 4:26 PM, sebb <sebbaz@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 <milamber@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.schumacher@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.mouawad@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.
>>>
>
>


Mime
View raw message