Re: Security/Versioning policy proposal
t; >>> if we want to EOL v3 in 2025 we will notify users in 2022) > > >>> 3. We backport and release security fixes (new feature or not) in all > > >>> maintained branches > > >>> > > >>> Wdyt? > > >>> > > >>> > > >>>> > > >>>> Am So., 18. Apr. 2021 um 22:45 Uhr schrieb Romain Manni-Bucau > > >>>> : > > >>>>> > > >>>>> Hi all, > > >>>>> > > >>>>> Back on this topic - which prepares v4 releases too btw. > > >>>>> > > >>>>> What do we finally write? > > >>>>> > > >>>>> That maven will always fix the latest (stable) version and can > > >> release > > >>>>> maintenance branches on demands (lazily)? > > >>>>> > > >>>>> Do we write 3.6 and 4 are active and maintained branches currently > or > > >>> do > > >>>> we > > >>>>> drop 3.x with first 4.x release? > > >>>>> > > >>>>> Indeed I'd like the 2 branches option but I am fine with whatever > > >>> policy > > >>>>> while written and clear for end users upfront. I'd love we solve > that > > >>>>> before next release if possible cause it always create pointless > work > > >>> due > > >>>>> to the blurry exchanges on this topic over our website and the > > >> net/mail > > >>>>> archives. > > >>>>> > > >>>>> > > >>>>> Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau > > >>>> a > > >>>>> écrit : > > >>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Le lun. 5 avr. 2021 à 17:42, Ralph Goers > > >>>> a > > >>>>>> écrit : > > >>>>>> > > >>>>>>> I don’t understand the point. The very next version of Maven did > > >> get > > >>>> the > > >>>>>>> security fix. Just because the release manager decided to follow > a > > >>>> peculiar > > >>>>>>> version numbering practice unique to Maven doesn’t mean there is > a > > >>>> problem. > > >>>>>>> > > >>>>>> > > >>>>>> This had been an issue only because the versioning policy of maven > > >> is > > >>>>>> undefined. > > >>>>>> If defined it is perfectly fine for me. > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> I don’t know what you mean by random, nor do I know what you mean > > >>> by a > > >>>>>>> stability statement. AFAIK Maven has been very stable from the > 2.x > > >>>> versions > > >>>>>>> through the 3.x versions. In some ways too stable, which is why > > >>>> introducing > > >>>>>>> new concepts that have been wanted for years is so hard. > > >>>>>>> > > >>>>>> > > >>>>>> Last statements tend to mean that once 4.x will be there, 3.x will > > >> be > > >>>>>> forgotten and no more maintained. > > >>>>>> Since it is a breaking change and if you picked 3.x today it is a > > >> big > > >>>> deal > > >>>>>> since you have no guarantee you can upgrade without a lot of > > >>>> investment and > > >>>>>> get security fixes when needed by just upgrading (and potentially > > >>>> tuning a > > >>>>>> bit the conf but not by rewriting the poms for ex). > > >>>>>> > > >>>>>> For 2.x -> 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 > > >>>>>> maven on their road too easily. > > >>>>>> If properly defin
Re: Security/Versioning policy proposal
rchives. > >>>>> > >>>>> > >>>>> Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau > >>>> a > >>>>> écrit : > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Le lun. 5 avr. 2021 à 17:42, Ralph Goers > >>>> a > >>>>>> écrit : > >>>>>> > >>>>>>> I don’t understand the point. The very next version of Maven did > >> get > >>>> the > >>>>>>> security fix. Just because the release manager decided to follow a > >>>> peculiar > >>>>>>> version numbering practice unique to Maven doesn’t mean there is a > >>>> problem. > >>>>>>> > >>>>>> > >>>>>> This had been an issue only because the versioning policy of maven > >> is > >>>>>> undefined. > >>>>>> If defined it is perfectly fine for me. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> I don’t know what you mean by random, nor do I know what you mean > >>> by a > >>>>>>> stability statement. AFAIK Maven has been very stable from the 2.x > >>>> versions > >>>>>>> through the 3.x versions. In some ways too stable, which is why > >>>> introducing > >>>>>>> new concepts that have been wanted for years is so hard. > >>>>>>> > >>>>>> > >>>>>> Last statements tend to mean that once 4.x will be there, 3.x will > >> be > >>>>>> forgotten and no more maintained. > >>>>>> Since it is a breaking change and if you picked 3.x today it is a > >> big > >>>> deal > >>>>>> since you have no guarantee you can upgrade without a lot of > >>>> investment and > >>>>>> get security fixes when needed by just upgrading (and potentially > >>>> tuning a > >>>>>> bit the conf but not by rewriting the poms for ex). > >>>>>> > >>>>>> For 2.x -> 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 > >>>>>> maven on their road too easily. > >>>>>> If properly defined it will not impact much maven dev but can save > >> a > >>>> lot > >>>>>> of time for enterprises and enable them to properly setup their > >>>> projects in > >>>>>> time. > >>>>>> > >>>>>> So overall the definition points are still the same: > >>>>>> > >>>>>> 1. which versions are maintained (ie can get 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. > >>>>>> > >>>>>> "3.x will be supported for 3 more years when 4.x is out and > >>> maintained > >>>>>> major versions are guaranteed to get security fixes" is a kind of > >>>> 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 > >>>>>> anymore" does not work for me for example IMHO (but we can put it > >> on > >>>> vote > >>>>>> if that's the community desire). > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> FWIW, my employer’s repository manager still uses http since it is > >>>> behind > >>>>>>> a VPN. After trying 3.8.1 I found I had to specify mirrors for all > >>> the > >>>>>>> repos even though they are not defined in pom’s. Apparently the > >> fix > >>>> also > >>>>>&
Re: Security/Versioning policy proposal
>>>>>> >>>>>>> >>>>>>> I don’t know what you mean by random, nor do I know what you mean >>> by a >>>>>>> stability statement. AFAIK Maven has been very stable from the 2.x >>>> versions >>>>>>> through the 3.x versions. In some ways too stable, which is why >>>> introducing >>>>>>> new concepts that have been wanted for years is so hard. >>>>>>> >>>>>> >>>>>> Last statements tend to mean that once 4.x will be there, 3.x will >> be >>>>>> forgotten and no more maintained. >>>>>> Since it is a breaking change and if you picked 3.x today it is a >> big >>>> deal >>>>>> since you have no guarantee you can upgrade without a lot of >>>> investment and >>>>>> get security fixes when needed by just upgrading (and potentially >>>> tuning a >>>>>> bit the conf but not by rewriting the poms for ex). >>>>>> >>>>>> For 2.x -> 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 >>>>>> maven on their road too easily. >>>>>> If properly defined it will not impact much maven dev but can save >> a >>>> lot >>>>>> of time for enterprises and enable them to properly setup their >>>> projects in >>>>>> time. >>>>>> >>>>>> So overall the definition points are still the same: >>>>>> >>>>>> 1. which versions are maintained (ie can get 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. >>>>>> >>>>>> "3.x will be supported for 3 more years when 4.x is out and >>> maintained >>>>>> major versions are guaranteed to get security fixes" is a kind of >>>> 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 >>>>>> anymore" does not work for me for example IMHO (but we can put it >> on >>>> vote >>>>>> if that's the community desire). >>>>>> >>>>>> >>>>>>> >>>>>>> FWIW, my employer’s repository manager still uses http since it is >>>> behind >>>>>>> a VPN. After trying 3.8.1 I found I had to specify mirrors for all >>> the >>>>>>> repos even though they are not defined in pom’s. Apparently the >> fix >>>> also >>>>>>> affects repositories defined in settings.xml. >>>>>>> >>>>>> >>>>>> Yes because it is a mirror and wildcard 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 know all of them by definition and mirroring >>> does >>>> not >>>>>> support custom patterns but can be a quick workaround to upgrade >>>> without >>>>>> blocking builds). >>>>>> >>>>>> >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>>> On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau >>>> rmannibu...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hmm, general/common asf way of doing is to move forward until >>> users >>>> ask >>>>>>>> (and if so any branch is patched while a pr is done). >>>>>>>> If maven does not follow that practise it cant say "last version >>>> will >>>>>>> get >>>>>>>> the security fix" too because it means "we dont care of users,
Re: Security/Versioning policy proposal
t; > > > statement I'm trying to get to let projects plan properly and not > > have > > > > > maven on their road too easily. > > > > > If properly defined it will not impact much maven dev but can save > a > > > lot > > > > > of time for enterprises and enable them to properly setup their > > > projects in > > > > > time. > > > > > > > > > > So overall the definition points are still the same: > > > > > > > > > > 1. which versions are maintained (ie can get 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. > > > > > > > > > > "3.x will be supported for 3 more years when 4.x is out and > > maintained > > > > > major versions are guaranteed to get security fixes" is a kind of > > > 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 > > > > > anymore" does not work for me for example IMHO (but we can put it > on > > > vote > > > > > if that's the community desire). > > > > > > > > > > > > > > >> > > > > >> FWIW, my employer’s repository manager still uses http since it is > > > behind > > > > >> a VPN. After trying 3.8.1 I found I had to specify mirrors for all > > the > > > > >> repos even though they are not defined in pom’s. Apparently the > fix > > > also > > > > >> affects repositories defined in settings.xml. > > > > >> > > > > > > > > > > Yes because it is a mirror and wildcard 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 know all of them by definition and mirroring > > does > > > not > > > > > support custom patterns but can be a quick workaround to upgrade > > > without > > > > > blocking builds). > > > > > > > > > > > > > > >> > > > > >> Ralph > > > > >> > > > > >> > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau > > > rmannibu...@gmail.com> > > > > >> wrote: > > > > >> > > > > > >> > Hmm, general/common asf way of doing is to move forward until > > users > > > ask > > > > >> > (and if so any branch is patched while a pr is done). > > > > >> > If maven does not follow 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". > > > > >> > 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? > > > > >> > > > > > >> > Le dim. 4 avr. 2021 à 22:13, Bernd Eckenfels > > > e...@zusammenkunft.net> a > > > > >> > écrit : > > > > >> > > > > > >> >> I agree, maven does not need to concern itself with branches as > > > long > > > > >> as it > > > > >> >> stays fairly forward drop-in compatible. > > > > >> >> > > > > >> >> Having said that, things like changing the policy for handling > > http > > > > >> might > > > > >> >> not be that drop-in, but on the other hand it’s just a config > > > option > > > > >> and > > > > >> >> does not require complicated (plugin) dependency updates. > > > > >> >> > > > > >> >> I do wonder if the version number shou
Re: Security/Versioning policy proposal
rt custom patterns but can be a quick workaround to upgrade > > without > > > > blocking builds). > > > > > > > > > > > >> > > > >> Ralph > > > >> > > > >> > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau > > rmannibu...@gmail.com> > > > >> wrote: > > > >> > > > > >> > Hmm, general/common asf way of doing is to move forward until > users > > ask > > > >> > (and if so any branch is patched while a pr is done). > > > >> > If maven does not follow 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". > > > >> > 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? > > > >> > > > > >> > Le dim. 4 avr. 2021 à 22:13, Bernd Eckenfels > > e...@zusammenkunft.net> a > > > >> > écrit : > > > >> > > > > >> >> I agree, maven does not need to concern itself with branches as > > long > > > >> as it > > > >> >> stays fairly forward drop-in compatible. > > > >> >> > > > >> >> Having said that, things like changing the policy for handling > http > > > >> might > > > >> >> not be that drop-in, but on the other hand it’s just a config > > option > > > >> 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 > > 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://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 > > > >> >> 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 > > > >> >> supporting Java 8. > > > >> >> > > > >> >> Ralph > > > >> >> > > > >> >>> On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau > > rmannibu...@gmail.com > > > >> > > > > >> >> wrote: > > > >> >>> > > > >> >>> 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 > > > >> >>> stability in their build - which is the goal of this thread. > > > >> >>> Since you rejected a 3.6.4 for last CVE hitting us I have to > > admit I > > > >> >> have a > > > >> >>&
Re: Security/Versioning policy proposal
the point. The very next version of Maven did get > the > > >> security fix. Just because the release manager decided to follow a > peculiar > > >> version numbering practice unique to Maven doesn’t mean there is a > problem. > > >> > > > > > > This had been an issue only because the versioning policy of maven is > > > undefined. > > > If defined it is perfectly fine for me. > > > > > > > > >> > > >> I don’t know what you mean by random, nor do I know what you mean by a > > >> stability statement. AFAIK Maven has been very stable from the 2.x > versions > > >> through the 3.x versions. In some ways too stable, which is why > introducing > > >> new concepts that have been wanted for years is so hard. > > >> > > > > > > Last statements tend to mean that once 4.x will be there, 3.x will be > > > forgotten and no more maintained. > > > Since it is a breaking change and if you picked 3.x today it is a big > deal > > > since you have no guarantee you can upgrade without a lot of > investment and > > > get security fixes when needed by just upgrading (and potentially > tuning a > > > bit the conf but not by rewriting the poms for ex). > > > > > > For 2.x -> 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 > > > maven on their road too easily. > > > If properly defined it will not impact much maven dev but can save a > lot > > > of time for enterprises and enable them to properly setup their > projects in > > > time. > > > > > > So overall the definition points are still the same: > > > > > > 1. which versions are maintained (ie can get 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. > > > > > > "3.x will be supported for 3 more years when 4.x is out and maintained > > > major versions are guaranteed to get security fixes" is a kind of > 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 > > > anymore" does not work for me for example IMHO (but we can put it on > vote > > > if that's the community desire). > > > > > > > > >> > > >> FWIW, my employer’s repository manager still uses http since it is > behind > > >> a VPN. After trying 3.8.1 I found I had to specify mirrors for all the > > >> repos even though they are not defined in pom’s. Apparently the fix > also > > >> affects repositories defined in settings.xml. > > >> > > > > > > Yes because it is a mirror and wildcard 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 know all of them by definition and mirroring does > not > > > support custom patterns but can be a quick workaround to upgrade > without > > > blocking builds). > > > > > > > > >> > > >> Ralph > > >> > > >> > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau > rmannibu...@gmail.com> > > >> wrote: > > >> > > > >> > Hmm, general/common asf way of doing is to move forward until users > ask > > >> > (and if so any branch is patched while a pr is done). > > >> > If maven does not follow 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". > > >> > 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? > > >> > > > >> > Le dim. 4 avr. 2021 à 22:13, Bernd Eckenfels > e...@zusammenkunft.net> a > > >> > écrit : > > >> > > > >> >> I agree, maven does not need to concern itself with branch
Re: Security/Versioning policy proposal
gt;> new concepts that have been wanted for years is so hard. > > >> > > > > > > Last statements tend to mean that once 4.x will be there, 3.x will be > > > forgotten and no more maintained. > > > Since it is a breaking change and if you picked 3.x today it is a big > deal > > > since you have no guarantee you can upgrade without a lot of > investment and > > > get security fixes when needed by just upgrading (and potentially > tuning a > > > bit the conf but not by rewriting the poms for ex). > > > > > > For 2.x -> 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 > > > maven on their road too easily. > > > If properly defined it will not impact much maven dev but can save a > lot > > > of time for enterprises and enable them to properly setup their > projects in > > > time. > > > > > > So overall the definition points are still the same: > > > > > > 1. which versions are maintained (ie can get 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. > > > > > > "3.x will be supported for 3 more years when 4.x is out and maintained > > > major versions are guaranteed to get security fixes" is a kind of > 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 > > > anymore" does not work for me for example IMHO (but we can put it on > vote > > > if that's the community desire). > > > > > > > > >> > > >> FWIW, my employer’s repository manager still uses http since it is > behind > > >> a VPN. After trying 3.8.1 I found I had to specify mirrors for all the > > >> repos even though they are not defined in pom’s. Apparently the fix > also > > >> affects repositories defined in settings.xml. > > >> > > > > > > Yes because it is a mirror and wildcard 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 know all of them by definition and mirroring does > not > > > support custom patterns but can be a quick workaround to upgrade > without > > > blocking builds). > > > > > > > > >> > > >> Ralph > > >> > > >> > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau < > rmannibu...@gmail.com> > > >> wrote: > > >> > > > >> > Hmm, general/common asf way of doing is to move forward until users > ask > > >> > (and if so any branch is patched while a pr is done). > > >> > If maven does not follow 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". > > >> > 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? > > >> > > > >> > Le dim. 4 avr. 2021 à 22:13, Bernd Eckenfels < > e...@zusammenkunft.net> a > > >> > écrit : > > >> > > > >> >> I agree, maven does not need to concern itself with branches as > long > > >> as it > > >> >> stays fairly forward drop-in compatible. > > >> >> > > >> >> Having said that, things like changing the policy for handling http > > >> might > > >> >> not be that drop-in, but on the other hand it’s just a config > option > > >> 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 > security > > >> >> fixes for those incompatible older bra
Re: Security/Versioning policy proposal
terns but can be a quick workaround to upgrade without > > blocking builds). > > > > > >> > >> Ralph > >> > >> > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau > >> wrote: > >> > > >> > Hmm, general/common asf way of doing is to move forward until users ask > >> > (and if so any branch is patched while a pr is done). > >> > If maven does not follow 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". > >> > 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? > >> > > >> > 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. > >> >> > >> >> Having said that, things like changing the policy for handling http > >> might > >> >> not be that drop-in, but on the other hand it’s just a config option > >> 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 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://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 > >> >> 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 > >> >> supporting Java 8. > >> >> > >> >> Ralph > >> >> > >> >>> On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau >> > > >> >> wrote: > >> >>> > >> >>> 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 > >> >>> stability in their build - which is the goal of this thread. > >> >>> Since you rejected a 3.6.4 for last CVE hitting us I have to admit I > >> >> have a > >> >>> hard time to formalize it. > >> >>> Best I come up is "we'll do what we want" which is hopefully just a > >> >>> complete misinterpretation of what you mean but hope shows how > >> clueless I > >> >>> am with such a statement at the moment. > >> >>> Can you try to refine it please? > >> >>> > >> >>> Concretely, today I'm starting with a 3.8.1, what am I expecting to > >> use > >> >> in > >> >>> 5 years for this project trying to get security fixes and being stable > >> >> (ie > >> >>> 4.x is assumed excluded?)? > >> >>> > >> >>> > >> >>>> > >> >>>> Robert > >> >>>> > >> >>>> On 4-4-2021 12:14:39, Romain Manni-Bucau > >> wrote: > >> >>>> Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit : > >> >>&g
Re: Security/Versioning policy proposal
>> might >> >> not be that drop-in, but on the other hand it’s just a config option >> 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 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://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 >> >> 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 >> >> supporting Java 8. >> >> >> >> Ralph >> >> >> >>> On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau > > >> >> wrote: >> >>> >> >>> 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 >> >>> stability in their build - which is the goal of this thread. >> >>> Since you rejected a 3.6.4 for last CVE hitting us I have to admit I >> >> have a >> >>> hard time to formalize it. >> >>> Best I come up is "we'll do what we want" which is hopefully just a >> >>> complete misinterpretation of what you mean but hope shows how >> clueless I >> >>> am with such a statement at the moment. >> >>> Can you try to refine it please? >> >>> >> >>> Concretely, today I'm starting with a 3.8.1, what am I expecting to >> use >> >> in >> >>> 5 years for this project trying to get security fixes and being stable >> >> (ie >> >>> 4.x is assumed excluded?)? >> >>> >> >>> >> >>>> >> >>>> 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 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 complex than: >> >>>>> bugfix release-change should be safe "just replace" release with >> >> bugfixes >> >>>>> and internal improvements. >> >>>>> minor release-change should represent relevant new features or (as >> we >> >> saw >> >>>>> for 3.8.x) possible breaking builds that can be fixed with >> >> configuration. >> >>>>> major release-change represents changes to the architecture that >> might >> >>>>> change the behavior. >> >>>>> as far as I know this defends all Maven releases up until now. >> >>>>> >> >>>> >> >>>> Does not cover the last release - and is actually the issue I'm >> >> suffering >> >>>> from right now and why i'd like we cover this case: security fixes. >> As >> >> of >> >>>> today it is a mix between patch (bugfix) and minor lines AFAIK but >> I'd >> >> like >> >>>> we explicit it (e
Re: Security/Versioning policy proposal
Le lun. 5 avr. 2021 à 17:42, Ralph Goers a écrit : > I don’t understand the point. The very next version of Maven did get the > security fix. Just because the release manager decided to follow a peculiar > version numbering practice unique to Maven doesn’t mean there is a problem. > This had been an issue only because the versioning policy of maven is undefined. If defined it is perfectly fine for me. > > I don’t know what you mean by random, nor do I know what you mean by a > stability statement. AFAIK Maven has been very stable from the 2.x versions > through the 3.x versions. In some ways too stable, which is why introducing > new concepts that have been wanted for years is so hard. > Last statements tend to mean that once 4.x will be there, 3.x will be forgotten and no more maintained. Since it is a breaking change and if you picked 3.x today it is a big deal since you have no guarantee you can upgrade without a lot of investment and get security fixes when needed by just upgrading (and potentially tuning a bit the conf but not by rewriting the poms for ex). For 2.x -> 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 maven on their road too easily. If properly defined it will not impact much maven dev but can save a lot of time for enterprises and enable them to properly setup their projects in time. So overall the definition points are still the same: 1. which versions are maintained (ie can get 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. "3.x will be supported for 3 more years when 4.x is out and maintained major versions are guaranteed to get security fixes" is a kind of 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 anymore" does not work for me for example IMHO (but we can put it on vote if that's the community desire). > > FWIW, my employer’s repository manager still uses http since it is behind > a VPN. After trying 3.8.1 I found I had to specify mirrors for all the > repos even though they are not defined in pom’s. Apparently the fix also > affects repositories defined in settings.xml. > Yes because it is a mirror and wildcard 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 know all of them by definition and mirroring does not support custom patterns but can be a quick workaround to upgrade without blocking builds). > > Ralph > > > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau > wrote: > > > > Hmm, general/common asf way of doing is to move forward until users ask > > (and if so any branch is patched while a pr is done). > > If maven does not follow 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". > > 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? > > > > 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. > >> > >> Having said that, things like changing the policy for handling http > might > >> not be that drop-in, but on the other hand it’s just a config option 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 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://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 > >> be. I can’t think of a case where Maven needed to go back and patch a > prior > >> release. That could happen ho
Re: Security/Versioning policy proposal
I don’t understand the point. The very next version of Maven did get the security fix. Just because the release manager decided to follow a peculiar version numbering practice unique to Maven doesn’t mean there is a problem. I don’t know what you mean by random, nor do I know what you mean by a stability statement. AFAIK Maven has been very stable from the 2.x versions through the 3.x versions. In some ways too stable, which is why introducing new concepts that have been wanted for years is so hard. FWIW, my employer’s repository manager still uses http since it is behind a VPN. After trying 3.8.1 I found I had to specify mirrors for all the repos even though they are not defined in pom’s. Apparently the fix also affects repositories defined in settings.xml. Ralph > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau wrote: > > Hmm, general/common asf way of doing is to move forward until users ask > (and if so any branch is patched while a pr is done). > If maven does not follow 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". > 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? > > 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. >> >> Having said that, things like changing the policy for handling http might >> not be that drop-in, but on the other hand it’s just a config option 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 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://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 >> 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 >> supporting Java 8. >> >> Ralph >> >>> On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau >> wrote: >>> >>> 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 >>> stability in their build - which is the goal of this thread. >>> Since you rejected a 3.6.4 for last CVE hitting us I have to admit I >> have a >>> hard time to formalize it. >>> Best I come up is "we'll do what we want" which is hopefully just a >>> complete misinterpretation of what you mean but hope shows how clueless I >>> am with such a statement at the moment. >>> Can you try to refine it please? >>> >>> Concretely, today I'm starting with a 3.8.1, what am I expecting to use >> in >>> 5 years for this project trying to get security fixes and being stable >> (ie >>> 4.x is assumed excluded?)? >>> >>> >>>> >>>> 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 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 complex than: >>>>> bugfix release-change should be safe "just replace" release with >> bugfixes >>>>> and internal improvements. >
Re: Security/Versioning policy proposal
Hmm, general/common asf way of doing is to move forward until users ask (and if so any branch is patched while a pr is done). If maven does not follow 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". 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? 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. > > Having said that, things like changing the policy for handling http might > not be that drop-in, but on the other hand it’s just a config option 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 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://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 > 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 > supporting Java 8. > > Ralph > > > On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau > wrote: > > > > 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 > > stability in their build - which is the goal of this thread. > > Since you rejected a 3.6.4 for last CVE hitting us I have to admit I > have a > > hard time to formalize it. > > Best I come up is "we'll do what we want" which is hopefully just a > > complete misinterpretation of what you mean but hope shows how clueless I > > am with such a statement at the moment. > > Can you try to refine it please? > > > > Concretely, today I'm starting with a 3.8.1, what am I expecting to use > in > > 5 years for this project trying to get security fixes and being stable > (ie > > 4.x is assumed excluded?)? > > > > > >> > >> 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 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 complex than: > >>> bugfix release-change should be safe "just replace" release with > bugfixes > >>> and internal improvements. > >>> minor release-change should represent relevant new features or (as we > saw > >>> for 3.8.x) possible breaking builds that can be fixed with > configuration. > >>> major release-change represents changes to the architecture that might > >>> change the behavior. > >>> as far as I know this defends all Maven releases up until now. > >>> > >> > >> Does not cover the last release - and is actually the issue I'm > suffering > >> from right now and why i'd like we cover this case: security fixes. As > of > >> today it is a mix between patch (bugfix) and minor lines AFAIK but I'd > like > >> we explicit it (even just saying on each line "can include bugfixes"). > >> Said differently: the reverse approach you mention only cover the > feature > >> evolution but not the most important for versioning policy: the security > >> policy which is the one which hurt right now. > >> As an user, I want to be able to anticipate the versions i can need > staying > >> as much as possible on a stable v
Re: Security/Versioning policy proposal
I agree, maven does not need to concern itself with branches as long as it stays fairly forward drop-in compatible. Having said that, things like changing the policy for handling http might not be that drop-in, but on the other hand it’s just a config option 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 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://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 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 supporting Java 8. Ralph > On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau wrote: > > 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 > stability in their build - which is the goal of this thread. > Since you rejected a 3.6.4 for last CVE hitting us I have to admit I have a > hard time to formalize it. > Best I come up is "we'll do what we want" which is hopefully just a > complete misinterpretation of what you mean but hope shows how clueless I > am with such a statement at the moment. > Can you try to refine it please? > > Concretely, today I'm starting with a 3.8.1, what am I expecting to use in > 5 years for this project trying to get security fixes and being stable (ie > 4.x is assumed excluded?)? > > >> >> 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 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 complex than: >>> bugfix release-change should be safe "just replace" release with bugfixes >>> and internal improvements. >>> minor release-change should represent relevant new features or (as we saw >>> for 3.8.x) possible breaking builds that can be fixed with configuration. >>> major release-change represents changes to the architecture that might >>> change the behavior. >>> as far as I know this defends all Maven releases up until now. >>> >> >> Does not cover the last release - and is actually the issue I'm suffering >> from right now and why i'd like we cover this case: security fixes. As of >> today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like >> we explicit it (even just saying on each line "can include bugfixes"). >> Said differently: the reverse approach you mention only cover the feature >> evolution but not the most important for versioning policy: the security >> policy which is the one which hurt right now. >> As an user, I want to be able to anticipate the versions i can need staying >> as much as possible on a stable version (original version) but upgrading to >> get security fixes. >> If it is fine for you to mention lines 1 and 2 can include security fixes >> i'd be to add this paragraph on the history page maybe? >> >> wdyt? >> >> >>> >>> In case of plugins: the major represents the minimal required version of >>> Maven. >>> >>> Robert >>> On 4-4-2021 11:28:30, Romain Manni-Bucau wrote: >>> 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 be a good >> start >>> with one or two more sentences to solve that. >>> >>> Le sam. 3 avr. 2021 à 23:50, Elliotte
Re: Security/Versioning policy proposal
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 supporting Java 8. Ralph > On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau wrote: > > 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 > stability in their build - which is the goal of this thread. > Since you rejected a 3.6.4 for last CVE hitting us I have to admit I have a > hard time to formalize it. > Best I come up is "we'll do what we want" which is hopefully just a > complete misinterpretation of what you mean but hope shows how clueless I > am with such a statement at the moment. > Can you try to refine it please? > > Concretely, today I'm starting with a 3.8.1, what am I expecting to use in > 5 years for this project trying to get security fixes and being stable (ie > 4.x is assumed excluded?)? > > >> >> 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 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 complex than: >>> bugfix release-change should be safe "just replace" release with bugfixes >>> and internal improvements. >>> minor release-change should represent relevant new features or (as we saw >>> for 3.8.x) possible breaking builds that can be fixed with configuration. >>> major release-change represents changes to the architecture that might >>> change the behavior. >>> as far as I know this defends all Maven releases up until now. >>> >> >> Does not cover the last release - and is actually the issue I'm suffering >> from right now and why i'd like we cover this case: security fixes. As of >> today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like >> we explicit it (even just saying on each line "can include bugfixes"). >> Said differently: the reverse approach you mention only cover the feature >> evolution but not the most important for versioning policy: the security >> policy which is the one which hurt right now. >> As an user, I want to be able to anticipate the versions i can need staying >> as much as possible on a stable version (original version) but upgrading to >> get security fixes. >> If it is fine for you to mention lines 1 and 2 can include security fixes >> i'd be to add this paragraph on the history page maybe? >> >> wdyt? >> >> >>> >>> In case of plugins: the major represents the minimal required version of >>> Maven. >>> >>> Robert >>> On 4-4-2021 11:28:30, Romain Manni-Bucau wrote: >>> 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 be a good >> start >>> with one or two more sentences to solve that. >>> >>> Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a >>> écrit : >>> 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 needed upgrades to have bugfixes. > TBH I don't think we have enough developer time and commitment to >> promise this. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Security/Versioning policy proposal
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 stability in their build - which is the goal of this thread. Since you rejected a 3.6.4 for last CVE hitting us I have to admit I have a hard time to formalize it. Best I come up is "we'll do what we want" which is hopefully just a complete misinterpretation of what you mean but hope shows how clueless I am with such a statement at the moment. Can you try to refine it please? Concretely, today I'm starting with a 3.8.1, what am I expecting to use in 5 years for this project trying to get security fixes and being stable (ie 4.x is assumed excluded?)? > > 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 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 complex than: > > bugfix release-change should be safe "just replace" release with bugfixes > > and internal improvements. > > minor release-change should represent relevant new features or (as we saw > > for 3.8.x) possible breaking builds that can be fixed with configuration. > > major release-change represents changes to the architecture that might > > change the behavior. > > as far as I know this defends all Maven releases up until now. > > > > Does not cover the last release - and is actually the issue I'm suffering > from right now and why i'd like we cover this case: security fixes. As of > today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like > we explicit it (even just saying on each line "can include bugfixes"). > Said differently: the reverse approach you mention only cover the feature > evolution but not the most important for versioning policy: the security > policy which is the one which hurt right now. > As an user, I want to be able to anticipate the versions i can need staying > as much as possible on a stable version (original version) but upgrading to > get security fixes. > If it is fine for you to mention lines 1 and 2 can include security fixes > i'd be to add this paragraph on the history page maybe? > > wdyt? > > > > > > In case of plugins: the major represents the minimal required version of > > Maven. > > > > Robert > > On 4-4-2021 11:28:30, Romain Manni-Bucau wrote: > > 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 be a good > start > > with one or two more sentences to solve that. > > > > Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a > > écrit : > > > > > 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 needed upgrades to have bugfixes. > > > > > > > > > > TBH I don't think we have enough developer time and commitment to > promise > > > this. > > > > > > -- > > > Elliotte Rusty Harold > > > elh...@ibiblio.org > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
Re: Security/Versioning policy proposal
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 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 complex than: > bugfix release-change should be safe "just replace" release with bugfixes > and internal improvements. > minor release-change should represent relevant new features or (as we saw > for 3.8.x) possible breaking builds that can be fixed with configuration. > major release-change represents changes to the architecture that might > change the behavior. > as far as I know this defends all Maven releases up until now. > Does not cover the last release - and is actually the issue I'm suffering from right now and why i'd like we cover this case: security fixes. As of today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like we explicit it (even just saying on each line "can include bugfixes"). Said differently: the reverse approach you mention only cover the feature evolution but not the most important for versioning policy: the security policy which is the one which hurt right now. As an user, I want to be able to anticipate the versions i can need staying as much as possible on a stable version (original version) but upgrading to get security fixes. If it is fine for you to mention lines 1 and 2 can include security fixes i'd be to add this paragraph on the history page maybe? wdyt? > > In case of plugins: the major represents the minimal required version of > Maven. > > Robert > On 4-4-2021 11:28:30, Romain Manni-Bucau wrote: > 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 be a good start > with one or two more sentences to solve that. > > Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a > écrit : > > > 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 needed upgrades to have bugfixes. > > > > > > > TBH I don't think we have enough developer time and commitment to promise > > this. > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: Security/Versioning policy proposal
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 differences > between version x and y. > > For Maven shouldn't be more complex than: > bugfix release-change should be safe "just replace" release with bugfixes > and internal improvements. > minor release-change should represent relevant new features or (as we saw > for 3.8.x) possible breaking builds that can be fixed with configuration. > major release-change represents changes to the architecture that might > change the behavior. > as far as I know this defends all Maven releases up until now. > Does not cover the last release - and is actually the issue I'm suffering from right now and why i'd like we cover this case: security fixes. As of today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like we explicit it (even just saying on each line "can include bugfixes"). Said differently: the reverse approach you mention only cover the feature evolution but not the most important for versioning policy: the security policy which is the one which hurt right now. As an user, I want to be able to anticipate the versions i can need staying as much as possible on a stable version (original version) but upgrading to get security fixes. If it is fine for you to mention lines 1 and 2 can include security fixes i'd be to add this paragraph on the history page maybe? wdyt? > > In case of plugins: the major represents the minimal required version of > Maven. > > Robert > On 4-4-2021 11:28:30, Romain Manni-Bucau wrote: > 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 be a good start > with one or two more sentences to solve that. > > Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a > écrit : > > > 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 needed upgrades to have bugfixes. > > > > > > > TBH I don't think we have enough developer time and commitment to promise > > this. > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: Security/Versioning policy proposal
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 complex than: bugfix release-change should be safe "just replace" release with bugfixes and internal improvements. minor release-change should represent relevant new features or (as we saw for 3.8.x) possible breaking builds that can be fixed with configuration. major release-change represents changes to the architecture that might change the behavior. as far as I know this defends all Maven releases up until now. In case of plugins: the major represents the minimal required version of Maven. Robert On 4-4-2021 11:28:30, Romain Manni-Bucau wrote: 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 be a good start with one or two more sentences to solve that. Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a écrit : > 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 needed upgrades to have bugfixes. > > > > TBH I don't think we have enough developer time and commitment to promise > this. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Security/Versioning policy proposal
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 be a good start with one or two more sentences to solve that. Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a écrit : > 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 needed upgrades to have bugfixes. > > > > TBH I don't think we have enough developer time and commitment to promise > this. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Security/Versioning policy proposal
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 needed upgrades to have bugfixes. > TBH I don't think we have enough developer time and commitment to promise this. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
