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, 02 Feb 2016 22:48:50 GMT
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
> <javascript:_e(%7B%7D,'cvml','sebbaz@gmail.com');>> wrote:
>
>> On 24 January 2016 at 11:30, Felix Schumacher
>> <felix.schumacher@internetallee.de
>> <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','ra0077@gmail.com');>>
>> >> wrote:
>> >>
>> >>> Hi
>> >>>
>> >>> 2016-01-13 21:43 GMT+01:00 Philippe Mouawad <
>> philippe.mouawad@gmail.com
>> <javascript:_e(%7B%7D,'cvml','philippe.mouawad@gmail.com');>>:
>> >>>
>> >>>> On Wed, Jan 13, 2016 at 5:28 PM, Antonio Gomes Rodrigues <
>> >>>
>> >>> ra0077@gmail.com <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','philippe.mouawad@gmail.com');>>
>> >>>>>>>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> First Happy new year 2016 !
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Mon, Jan 4, 2016 at 4:26 PM, sebb <sebbaz@gmail.com
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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.

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