Re: Defining EoL for Older Maven Versions

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Defining EoL for Older Maven Versions

michaelo
Am 2019-12-14 um 12:31 schrieb Karl Heinz Marbaise:

> Hi,
>
> based on the history we have defined Maven 2.X EoL five years after the
> last release...[1]
>
> Based on that I would suggest to define End Of Life for the following
> Maven versions cause their release date is also five years ago...
>
>
> Maven 3.0.5...3.2.5 included.
>
> We have never backported some things in the last five year...
>
> WDYT?

That sounds like a plan, but not honest enough. If we include 3.3.9 and
3.5.4 we ultimately say that we still support this and patch it. But we
don't! In tickets we require always to try to the latest version.

What I would see as honest is that we would support 3.6.x with bugfixes
for some amount of time and have a line moving forward, 3.7.x.
Everything else is just a lie.

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Defining EoL for Older Maven Versions

Aleksandar Kurtakov
On Sat, Dec 14, 2019 at 1:50 PM Michael Osipov <[hidden email]> wrote:

> Am 2019-12-14 um 12:31 schrieb Karl Heinz Marbaise:
> > Hi,
> >
> > based on the history we have defined Maven 2.X EoL five years after the
> > last release...[1]
> >
> > Based on that I would suggest to define End Of Life for the following
> > Maven versions cause their release date is also five years ago...
> >
> >
> > Maven 3.0.5...3.2.5 included.
> >
> > We have never backported some things in the last five year...
> >
> > WDYT?
>
> That sounds like a plan, but not honest enough. If we include 3.3.9 and
> 3.5.4 we ultimately say that we still support this and patch it. But we
> don't! In tickets we require always to try to the latest version.
>
> What I would see as honest is that we would support 3.6.x with bugfixes
> for some amount of time and have a line moving forward, 3.7.x.
> Everything else is just a lie.
>

+1. Setting clear expectations is better than letting people live with
their (false) hopes.


>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Alexander Kurtakov
Red Hat Eclipse Team
Reply | Threaded
Open this post in threaded view
|

Re: Defining EoL for Older Maven Versions

Benjamin Marwell
In reply to this post by michaelo
I do know companies who still use 3.2.3 and they don't dare to update
because of a misconfiguration.
Should we care? Or perhaps they should have bought support contracts
for such use cases?

If we say "support the 3.6 branch fur such amount of time" it also
means reacting to vulnerabilities in time, doesn't it?

But yes, better have a clear statement than no statement at all.

Am Sa., 14. Dez. 2019 um 12:43 Uhr schrieb Michael Osipov <[hidden email]>:

>
> Am 2019-12-14 um 12:31 schrieb Karl Heinz Marbaise:
> > Hi,
> >
> > based on the history we have defined Maven 2.X EoL five years after the
> > last release...[1]
> >
> > Based on that I would suggest to define End Of Life for the following
> > Maven versions cause their release date is also five years ago...
> >
> >
> > Maven 3.0.5...3.2.5 included.
> >
> > We have never backported some things in the last five year...
> >
> > WDYT?
>
> That sounds like a plan, but not honest enough. If we include 3.3.9 and
> 3.5.4 we ultimately say that we still support this and patch it. But we
> don't! In tickets we require always to try to the latest version.
>
> What I would see as honest is that we would support 3.6.x with bugfixes
> for some amount of time and have a line moving forward, 3.7.x.
> Everything else is just a lie.
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Defining EoL for Older Maven Versions

Karl Heinz Marbaise-3
Hi,

On 14.12.19 12:59, Benjamin Marwell wrote:
> I do know companies who still use 3.2.3 and they don't dare to update
> because of a misconfiguration.

If we start to use this argument we need to go back and support Maven 2
as well cause it's used somewhere in the wild ...


> Should we care? Or perhaps they should have bought support contracts
> for such use cases?

If people don't upgrade/maintain their build for more than five++ years
I think there is a big issue...

And yes maybe the should find some consultant to fix their issues...

Kind regards
Karl Heinz Marbaise



>
> If we say "support the 3.6 branch fur such amount of time" it also
> means reacting to vulnerabilities in time, doesn't it?
>
> But yes, better have a clear statement than no statement at all.
>
> Am Sa., 14. Dez. 2019 um 12:43 Uhr schrieb Michael Osipov <[hidden email]>:
>>
>> Am 2019-12-14 um 12:31 schrieb Karl Heinz Marbaise:
>>> Hi,
>>>
>>> based on the history we have defined Maven 2.X EoL five years after the
>>> last release...[1]
>>>
>>> Based on that I would suggest to define End Of Life for the following
>>> Maven versions cause their release date is also five years ago...
>>>
>>>
>>> Maven 3.0.5...3.2.5 included.
>>>
>>> We have never backported some things in the last five year...
>>>
>>> WDYT?
>>
>> That sounds like a plan, but not honest enough. If we include 3.3.9 and
>> 3.5.4 we ultimately say that we still support this and patch it. But we
>> don't! In tickets we require always to try to the latest version.
>>
>> What I would see as honest is that we would support 3.6.x with bugfixes
>> for some amount of time and have a line moving forward, 3.7.x.
>> Everything else is just a lie.
>>
>> Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Defining EoL for Older Maven Versions

michaelo
In reply to this post by michaelo
If so, we have to define what "Support" and "Test" mean and post that on
the website. I think this is an issue!

M

Am 2019-12-14 um 13:07 schrieb Karl Heinz Marbaise:

> Hi,
>
> I have a different opionion about End Of Life ...
>
> at moment we are only testing our plugins with Maven 3.2.5 as lowest
> version... we had the same dicussion more than a year before[1].
>
> I see it simply as that:
>
> We don't test all our plugins against versions like:
>
> 3.0.5, 3.1.1
>
> This implies those plugins versions are not active being tested via our
> CI...
>
> The lowest version which we are currently testing is 3.2.5 see [2] and [3]
>
> Apart from that:
>
> The implication saying we define EoL for version X does not mean we will
> backport some issues to other versions....maybe we decide to do that
> based on Security issue etc. (the only reason I can imagine to do that)..
>
> Furthermore the part you have suggest to support 3.6.X line with patches
> for a time has never been done for earlier versions as well. We alway
> work on most recent version..as you already mention we recommend in all
> tickets to upgrade first...that strategy should being kept..
>
>
>  From my point of view we should lift a new baseline to Maven 3.3.9 as
> lowest version...any other version should be define as End Of Life...
>
>
>
> Kind regards
> Karl Heinz Marbaise
>
> [1]
> https://lists.apache.org/thread.html/9e0d47814e84b75ac87bc88c84c1c029fe4b63beed46c82dab1121b9%40%3Cdev.maven.apache.org%3E 
>
> [2]
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/master/ 
>
> [3]
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-compiler-plugin/job/master/ 
>
>
> On 14.12.19 12:43, Michael Osipov wrote:
>> Am 2019-12-14 um 12:31 schrieb Karl Heinz Marbaise:
>>> Hi,
>>>
>>> based on the history we have defined Maven 2.X EoL five years after the
>>> last release...[1]
>>>
>>> Based on that I would suggest to define End Of Life for the following
>>> Maven versions cause their release date is also five years ago...
>>>
>>>
>>> Maven 3.0.5...3.2.5 included.
>>>
>>> We have never backported some things in the last five year...
>>>
>>> WDYT?
>>
>> That sounds like a plan, but not honest enough. If we include 3.3.9 and
>> 3.5.4 we ultimately say that we still support this and patch it. But we
>> don't! In tickets we require always to try to the latest version.
>>
>> What I would see as honest is that we would support 3.6.x with bugfixes
>> for some amount of time and have a line moving forward, 3.7.x.
>> Everything else is just a lie.
>>
>> Michael
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Defining EoL for Older Maven Versions

Elliotte Rusty Harold
In reply to this post by michaelo
Tentative +1.

Is there any reason we would ever backport a fix to 3.0 or 3.2? E.g.
this was the last release to support Java 1.6.

Or would we simply tell users to upgrade to 3.6.3?


On Sat, Dec 14, 2019 at 6:31 AM Karl Heinz Marbaise <[hidden email]> wrote:

>
> Hi,
>
> based on the history we have defined Maven 2.X EoL five years after the
> last release...[1]
>
> Based on that I would suggest to define End Of Life for the following
> Maven versions cause their release date is also five years ago...
>
>
> Maven 3.0.5...3.2.5 included.
>
> We have never backported some things in the last five year...
>
> WDYT?
>
> Kind regards
> Karl Heinz Marbaise
>
>
> [1]: https://maven.apache.org/docs/history.html#Maven_2
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]