gt; 3.x time, the 2.x was maintained some years.
> > >>>>>> This is very close to the LTS concept, and this is mainly this
> kind
> > >>> of
> > >>>>>> statement I'm trying to get to let projects plan properly and not
> > >>> have
> > >>>>>
security fixes - new
> >>>> features
> >>>>>> are not required to be in the box here)
> >>>>>> 2. for how long
> >>>>>> 3. what does mean version (major.minor.*, major.* for ex) in 1.
> >>>>>>
> >>&g
t;>>> statement
>>>>>> which solves that - we can also use N=current and N+1 in the
>>> statement
>>>> to
>>>>>> not stick it to 3 and 4.
>>>>>> "4.x is the current released branch, other branch will never be
>>>> released
&g
one.
> > > > > Using a custom global settings - to override default one - is a
> > > solution
> > > > > if you know all http repositories you want to force to be blocked
> > (can
> > > be
> > > > > hard since you never
> > > >
> > > >
> > > >>
> > > >> Ralph
> > > >>
> > > >> > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau
> > rmannibu...@gmail.com>
> > > >> wrote:
> > > >> >
> >
ollow that practise it cant say "last version
> will
> > >> get
> > >> > the security fix" too because it means "we dont care of users, to
> get
> > >> the
> > >> > cve fix you will have to rewrite your build".
> > >> >
>> > cve fix you will have to rewrite your build".
> > >> > So at least a major stability statement is required IMO with some
> lts
> > >> > statement and eol on majors.
> > >> > Without that using maven sounds random for projects, no?
> > >
gt;
> >> > Le dim. 4 avr. 2021 à 22:13, Bernd Eckenfels a
> >> > écrit :
> >> >
> >> >> I agree, maven does not need to concern itself with branches as long
> >> as it
> >> >> stays fairly forward drop-in compatible.
> >> >>
>
tion
>> and
>> >> does not require complicated (plugin) dependency updates.
>> >>
>> >> I do wonder if the version number should better reflect such
>> incompatible
>> >> requirement changes. (And if somebody really wants to provide securit
gt;> requirement changes. (And if somebody really wants to provide security
> >> fixes for those incompatible older branches why not, but I don’t think
> you
> >> can require them from a project which does not offer them by themself).
> >>
> >>
> >> --
> >> http://b
you
>> can require them from a project which does not offer them by themself).
>>
>>
>> --
>> http://bernd.eckenfels.net
>> ________
>> Von: Ralph Goers
>> Gesendet: Sunday, April 4, 2021 9:55:50 PM
>> An: Maven Deve
ich does not offer them by themself).
>
>
> --
> http://bernd.eckenfels.net
>
> Von: Ralph Goers
> Gesendet: Sunday, April 4, 2021 9:55:50 PM
> An: Maven Developers List
> Betreff: Re: Security/Versioning policy proposal
>
> More than likely
offer them by themself).
--
http://bernd.eckenfels.net
Von: Ralph Goers
Gesendet: Sunday, April 4, 2021 9:55:50 PM
An: Maven Developers List
Betreff: Re: Security/Versioning policy proposal
More than likely you will get whatever the next version number happens to
More than likely you will get whatever the next version number happens to be. I
can’t think of a case where Maven needed to go back and patch a prior release.
That could happen however, if Maven was modified to require Java 11 to run and
a security fix had to be applied to the last version supp
Le dim. 4 avr. 2021 à 14:10, Robert Scholte a écrit :
> To me all releases can contain security fixes.
> Depending on the risk of the CVE we can decide to do a release with only
> those fixes (see Maven 3.0.5 and 3.8.1)
>
I get that but it does not help users to pick versions and to get any
stab
To me all releases can contain security fixes.
Depending on the risk of the CVE we can decide to do a release with only those
fixes (see Maven 3.0.5 and 3.8.1)
Robert
On 4-4-2021 12:14:39, Romain Manni-Bucau wrote:
Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit :
> I doubt we can or shoul
Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit :
> I doubt we can or should make any promises, only intentions.
> If we would have it, I wonder if it cover our choice to skip 3.7.0.
> To me we need to keep that flexibility.
>
> I want to reverse the approach: what could users expect as diffe
I doubt we can or should make any promises, only intentions.
If we would have it, I wonder if it cover our choice to skip 3.7.0.
To me we need to keep that flexibility.
I want to reverse the approach: what could users expect as differences between
version x and y.
For Maven shouldn't be more com
Hi Elliotte,
My goal is to write what we can promise and users can rely on to work.
If we can only promise any major release will get all security fixes
whatever are the minor/patch versions, be it.
I just want what we do to be explicit.
Hervé proposed to reference history page of website, it can
On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau wrote:
>
> Hi all,
>
> What about starting from something like
> http://tomee.apache.org/security/security.html for our versioning policy.
>
> Goal is really to let user plan their versioning policy and ensure there is
> no big surprises in the nee
Hi all,
What about starting from something like
http://tomee.apache.org/security/security.html for our versioning policy.
Goal is really to let user plan their versioning policy and ensure there is
no big surprises in the needed upgrades to have bugfixes.
The tomee one spiritI aligns on the 3.6/
21 matches
Mail list logo
