Re: Security/Versioning policy proposal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Security/Versioning policy proposal

Romain Manni-Bucau
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 <[hidden email]> a
écrit :

> On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau <[hidden email]>
> 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
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Security/Versioning policy proposal

rfscholte
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 <[hidden email]> 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
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Security/Versioning policy proposal

rfscholte
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 <[hidden email]> 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
> > [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Security/Versioning policy proposal

Romain Manni-Bucau
Le dim. 4 avr. 2021 à 14:10, Robert Scholte <[hidden email]> 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 <[hidden email]> 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
> > > [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>