jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Release a 3.0
Date Tue, 09 Feb 2016 20:09:58 GMT
On Tue, Feb 9, 2016 at 8:01 PM, sebb <sebbaz@gmail.com> wrote:

> On 8 February 2016 at 11:58, Philippe Mouawad
> <philippe.mouawad@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.mouawad@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.mouawad@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 <sebbaz@gmail.com> wrote:
> >>>
> >>>> On 24 January 2016 at 11:30, Felix Schumacher
> >>>> <felix.schumacher@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
> >>>> >> <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.
> >>>> >>>>
> >>>> >>
> >>>> >>
> >>>> >
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Cordialement.
> >>> Philippe Mouawad.
> >>>
> >>>
> >>>
> >>
> >> --
> >> Cordialement.
> >> Philippe Mouawad.
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message