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 <rmannibu...@gmail.com> 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
>
>

Reply via email to