JMeter version numbering

[Philippe Mouawad <ph...@gmail.com>]

Hello,
I wonder if our versioning strategy is correct if we are supposed to follow
:

   - http://semver.org/


For example, 3.1 and 3.2 should maybe have been named 4.0.0 and 5.0.0
because they both broke backward compatibility by deprecating/removing
elements.

Besides, in terms of communication, they were not minor at all.
Maybe it's time to change this as if you have noticed it, I have read
things like:

   - This is the first major version of JMeter in over 12 years

Which is kind of non sense for me knowing all the features that have been
introduced in 2.X "minor" versions.

Regards

-- 
Cordialement.
Philippe Mouawad.

Re: JMeter version numbering

[sebb <se...@gmail.com>]

On 29 May 2017 at 22:48, Philippe Mouawad <ph...@gmail.com> wrote:
> On Monday, May 29, 2017, sebb <se...@gmail.com> wrote:
>
>> On 29 May 2017 at 21:57, Philippe Mouawad <philippe.mouawad@gmail.com
>> <javascript:;>> wrote:
>> > Hello,
>> > I wonder if our versioning strategy is correct if we are supposed to
>> follow
>> > :
>> >
>> >    - http://semver.org/
>> >
>>
>> No, we do not have to follow that.
>> [AFAIK, it was not even in existence when JMeter started]
>>
>> It's up to individual projects to agree on what to versioning strategy to
>> use.
>>
>> Semantic versioning may or may not be suitable.
>
> it looks like a standard no ?
>

AFAIK it's just someone's idea of a strategy which they have documented.

It is fairly widely used, but I don't think it is a formal standard.

AFAICT it does not say anything about requiring a major version bump
if there is new functionality.
This seems to be something you are expecting, so it may not be suitable.

>
>>
>> But I agree the versioning strategy needs to be documented.
>
> yes
>
>>
>> > For example, 3.1 and 3.2 should maybe have been named 4.0.0 and 5.0.0
>> > because they both broke backward compatibility by deprecating/removing
>> > elements.
>>
>> Possibly.
>>
>> > Besides, in terms of communication, they were not minor at all.
>> > Maybe it's time to change this as if you have noticed it, I have read
>> > things like:
>> >
>> >    - This is the first major version of JMeter in over 12 years
>> >
>> > Which is kind of non sense for me knowing all the features that have been
>> > introduced in 2.X "minor" versions.
>>
>> Yes, it is nonsense.
>>
>> Note that major version bumps may be seen by some as negative.
>> There are lots of projects where a major bump always means
>> incompatible changes, with changes required to use them.
>
>
> probably , but I think we take special care of being able to read plans in
> older versions and document all changes and breaking ones.

Yes, JMeter has always strived to ensure that test plans are upwards compatible.

But that does not mean that people won't think that a major bump means
existing test plans will break.
I have seen that raised as an issue in the past.

>
>> The project should not base its versioning strategy on what 3rd parties
>> write.
>> It needs to decide the strategy independently, document it carefully,
>> and ensure it is adhered to going forward.
>
>
> I think it was unfortunately a rather common perception,  talking with
> other testers, they sometimes tell me they didn't find interest in
> upgrading as it was a minor version.

And others will say they are worried about upgrading to a new major
version because they think it may break compatibility.

> We cannot live isolated from what is written on project and need to either
> inform or take it into account.

The Release Notes and announcement email need to be very clear on the
consequences of upgrading or not.

>
>> > Regards
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: JMeter version numbering

[Felix Schumacher <fe...@internetallee.de>]

Am 29.05.2017 um 23:48 schrieb Philippe Mouawad:
> On Monday, May 29, 2017, sebb <se...@gmail.com> wrote:
>
>> On 29 May 2017 at 21:57, Philippe Mouawad <philippe.mouawad@gmail.com
>> <javascript:;>> wrote:
>>> Hello,
>>> I wonder if our versioning strategy is correct if we are supposed to
>> follow
>>> :
>>>
>>>     - http://semver.org/
>>>
>> No, we do not have to follow that.
>> [AFAIK, it was not even in existence when JMeter started]
>>
>> It's up to individual projects to agree on what to versioning strategy to
>> use.
>>
>> Semantic versioning may or may not be suitable.
> it looks like a standard no ?
I would say semantiv versioning (semver) is a standard, but not the only 
one.
If I remember it correctly, we had a discussion, whether we should 
follow semver with our release numbers. I think we were OK with using 
it, but could not really commit on what changes would be OK to make, 
even if they would break backward compatibility, when the API was 
thought of private.

On the other hand, JMeter has a wide user base and we should strife to 
keep the tests as backward compatible as possible, regardless what 
version scheme we are using.
>
>
>
>> But I agree the versioning strategy needs to be documented.
> yes
>
>>> For example, 3.1 and 3.2 should maybe have been named 4.0.0 and 5.0.0
>>> because they both broke backward compatibility by deprecating/removing
>>> elements.
>> Possibly.
>>
>>> Besides, in terms of communication, they were not minor at all.
>>> Maybe it's time to change this as if you have noticed it, I have read
>>> things like:
>>>
>>>     - This is the first major version of JMeter in over 12 years
>>>
>>> Which is kind of non sense for me knowing all the features that have been
>>> introduced in 2.X "minor" versions.
>> Yes, it is nonsense.
>>
>> Note that major version bumps may be seen by some as negative.
>> There are lots of projects where a major bump always means
>> incompatible changes, with changes required to use them.
>
> probably , but I think we take special care of being able to read plans in
> older versions and document all changes and breaking ones.
>
>
>> The project should not base its versioning strategy on what 3rd parties
>> write.
>> It needs to decide the strategy independently, document it carefully,
>> and ensure it is adhered to going forward.
>
> I think it was unfortunately a rather common perception,  talking with
> other testers, they sometimes tell me they didn't find interest in
> upgrading as it was a minor version.
>
> We cannot live isolated from what is written on project and need to either
> inform or take it into account.
I have seen coverage for all "major" minor versions (3.1 and 3.2) of the 
3.x releases, so third parties seem to think they are important :)

I am happy with the release numbering scheme we have right now, which I 
see as: Try to keep backwards compatibility (stronger in "public" apis, 
than in "private" apis) and improve in small steps.

Regards,
  Felix
>
>
>>> Regards
>>>
>>> --
>>> Cordialement.
>>> Philippe Mouawad.
>

Re: JMeter version numbering

[Philippe Mouawad <ph...@gmail.com>]

On Monday, May 29, 2017, sebb <se...@gmail.com> wrote:

> On 29 May 2017 at 21:57, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>> wrote:
> > Hello,
> > I wonder if our versioning strategy is correct if we are supposed to
> follow
> > :
> >
> >    - http://semver.org/
> >
>
> No, we do not have to follow that.
> [AFAIK, it was not even in existence when JMeter started]
>
> It's up to individual projects to agree on what to versioning strategy to
> use.
>
> Semantic versioning may or may not be suitable.

it looks like a standard no ?



>
> But I agree the versioning strategy needs to be documented.

yes

>
> > For example, 3.1 and 3.2 should maybe have been named 4.0.0 and 5.0.0
> > because they both broke backward compatibility by deprecating/removing
> > elements.
>
> Possibly.
>
> > Besides, in terms of communication, they were not minor at all.
> > Maybe it's time to change this as if you have noticed it, I have read
> > things like:
> >
> >    - This is the first major version of JMeter in over 12 years
> >
> > Which is kind of non sense for me knowing all the features that have been
> > introduced in 2.X "minor" versions.
>
> Yes, it is nonsense.
>
> Note that major version bumps may be seen by some as negative.
> There are lots of projects where a major bump always means
> incompatible changes, with changes required to use them.


probably , but I think we take special care of being able to read plans in
older versions and document all changes and breaking ones.


> The project should not base its versioning strategy on what 3rd parties
> write.
> It needs to decide the strategy independently, document it carefully,
> and ensure it is adhered to going forward.


I think it was unfortunately a rather common perception,  talking with
other testers, they sometimes tell me they didn't find interest in
upgrading as it was a minor version.

We cannot live isolated from what is written on project and need to either
inform or take it into account.


> > Regards
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>


-- 
Cordialement.
Philippe Mouawad.

Re: JMeter version numbering

[sebb <se...@gmail.com>]

On 29 May 2017 at 21:57, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello,
> I wonder if our versioning strategy is correct if we are supposed to follow
> :
>
>    - http://semver.org/
>

No, we do not have to follow that.
[AFAIK, it was not even in existence when JMeter started]

It's up to individual projects to agree on what to versioning strategy to use.

Semantic versioning may or may not be suitable.

But I agree the versioning strategy needs to be documented.

> For example, 3.1 and 3.2 should maybe have been named 4.0.0 and 5.0.0
> because they both broke backward compatibility by deprecating/removing
> elements.

Possibly.

> Besides, in terms of communication, they were not minor at all.
> Maybe it's time to change this as if you have noticed it, I have read
> things like:
>
>    - This is the first major version of JMeter in over 12 years
>
> Which is kind of non sense for me knowing all the features that have been
> introduced in 2.X "minor" versions.

Yes, it is nonsense.

Note that major version bumps may be seen by some as negative.
There are lots of projects where a major bump always means
incompatible changes, with changes required to use them.

The project should not base its versioning strategy on what 3rd parties write.
It needs to decide the strategy independently, document it carefully,
and ensure it is adhered to going forward.

> Regards
>
> --
> Cordialement.
> Philippe Mouawad.