In message <> on Tue, 25 Sep 
2018 14:15:32 +0100, Matt Caswell <> said:

> On 25/09/18 14:09, Tim Hudson wrote:
> > It would also mean our LTS releases are MAJOR.MINOR - as the PATCH is
> > the fixes we will apply - so it isn't part of the LTS designation as such.
> > e.g. 5.0.x would be the marker - not 5.0.0 - so 5.0 in shorthand form. 
> This is where we disagree. My proposal is that the LTS designation would
> be 5 (not 5.0.x or 5.0.0). We would continue to do updates as we have
> done except we would have to classify our changes on the LTS branch as
> either API affecting (e.g. new accessor) or just a bug fix. If the
> former then the new version becomes an update to the MINOR number,
> otherwise it is an update to the PATCH number.

I *like* the idea of an LTS designation on the major number only.
However, the rest leaves me utterly confused.  Here, it seems that you
would allow a 5.1.0 minor update in the v5 LTS branch, and yet, you
say this when responding to my posting:

In message <> on Tue, 25 Sep 
2018 14:18:17 +0100, Matt Caswell <> said:

> On 25/09/18 13:25, Richard Levitte wrote:
> > Added accessors is additions to out API, not a change of our existing
> > API, let's make that clear.  The choice we can make in the scenario is
> > to either release 5.2.0 or 6.0.0.  In my mind, both are viable, but
> > for different reasons.
> Neither seems viable to me. That would mean you have to add all the
> features from 5.1.0 into an LTS release. That can't happen.

I think I need an example timeline from you, 'cause I can see clearly
how you look at it...


Richard Levitte
OpenSSL Project
openssl-project mailing list

Reply via email to