Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

In message <20180922.075955.1307478942356074896.levi...@openssl.org> on Sat, 22 Sep 2018 07:59:55 +0200 (CEST), Richard Levitte said: > So far, we've basically seen two proposed solutions to the problem: > ... > > - the other goes to the semantics of the encoded version number > according to

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

In message <056a59ce-2f19-43ae-b2e8-290ecb3d0...@dukhovni.org> on Sat, 22 Sep 2018 01:02:29 -0400, Viktor Dukhovni said: > > > > On Sep 22, 2018, at 12:59 AM, Richard Levitte wrote: > > > > So in summary, do we agree on this, and that it's a good path forward? > > > > - semantic versioning

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On Sat, Sep 22, 2018 at 3:12 PM Viktor Dukhovni wrote: > The proposal to move the minor version into nibbles 2 and 3 breaks this > OpenSSH function. > No it doesn't - because I'm not talking about moving *anything* in the current encoding for major and minor - see earlier post. The positions don

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

If you accept that we have a MAJOR.MINOR.FIX.PATCH encoding currently documented and in place and that the encoding in OPENSSL_VERSION_NUMBER is documented then the semantic versioning is an easy change. We do not need to change our encoding of MAJOR.MINOR - that is documented and fixed. We just ne

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 22, 2018, at 12:50 AM, Tim Hudson wrote: > > The impact of the breaking change on anyone actually following our documented > encoding cannot. > i.e. openssh as one example Richard pointed out. The only use of OPENSSL_VERSION_NUMBER bits in OpenSSH (which is not yet ported to 1.1.x

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 22, 2018, at 12:59 AM, Richard Levitte wrote: > > So in summary, do we agree on this, and that it's a good path forward? > > - semantic versioning scheme good, we should adopt it. > - we need to agree on how to translate that in code. > - we need to stop fighting about history. Yes.

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

This was a lot. Can I start with asking that we stop referring to enigmatic users? They are diverse and so are their views on this (if not just utter confusion when they can't make sense of how our version numbers change... The Wikipedia article may be reflection of that, or it might be that its

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On Sat, Sep 22, 2018 at 11:55 AM Viktor Dukhovni wrote: > this is an ad-hoc encoding with monitonicity as the > the only constraint. > If you start from the position that the encoding of OPENSSL_VERSION_NUMBER is free to change so long as the resulting value is larger than what we have been usin

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 9:28 PM, Tim Hudson wrote: > > That parsing of history I think is at best a stretch and not supportable and > also not what our users think. This isn't a mathematical theorem or even a legal debate. We should do what makes the most sense going forward. Richar proposes, an

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On Sat, 22 Sep. 2018, 3:24 am Viktor Dukhovni, wrote: > > On Sep 21, 2018, at 12:50 PM, Tim Hudson wrote: > > If that is the case then our current practice of allowing ABI breakage > with > > minor release changes (the middle number we document as the minor > release number) > > has to change. >

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 4:55 PM, Richard Levitte wrote: > > I think we need to get rid of OPENSSL_VERSION_NUMBER. Absolutely not. That's the one thing we must keep, and keep monotone so that applications continue to compile and build. Sure we need to communicate our ABI/API stability policies

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

In message on Sat, 22 Sep 2018 00:07:47 +1000, Tim Hudson said: > In semantic versioning terms this is what it would mean. > And if you want to check release/alpha/beta status you look at the > OPENSSL_VERSION_PRE_RELEASE macro and we stop the release+alpha+beta > indicator usage in the OPENSSL

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 4:01 PM, Richard Levitte wrote: > > For pre-processing, that might be different, I have no clue how people > figure out the exact number to compare OPENSSL_VERSION_NUMBER... I > assume, though, that they follow the path of least resistance and > simply pick the current numb

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

In message <22dffd58-5686-4fd6-bbb7-00512cc88...@dukhovni.org> on Fri, 21 Sep 2018 12:29:43 -0400, Viktor Dukhovni said: > > > > On Sep 21, 2018, at 12:14 PM, Matt Caswell wrote: > > > > I support Richard's proposal with an epoch of 1. > > Grudgingly I would accept an epoch in the 3-8 range.

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 12:50 PM, Tim Hudson wrote: > If that is the case then our current practice of allowing ABI breakage with > minor release changes (the middle number we document as the minor release > number) > has to change. CORRECTION: As advertised when 1.0.0 first came out, and rep

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On Sat, 22 Sep. 2018, 2:29 am Viktor Dukhovni, wrote: > > > > On Sep 21, 2018, at 12:14 PM, Matt Caswell wrote: > > > > I support Richard's proposal with an epoch of 1. > > Grudgingly I would accept an epoch in the 3-8 range. > > I would oppose an epoch of 2. > > I can live with that, though it

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On 21/09/18 17:29, Viktor Dukhovni wrote: > > >> On Sep 21, 2018, at 12:14 PM, Matt Caswell wrote: >> >> I support Richard's proposal with an epoch of 1. >> Grudgingly I would accept an epoch in the 3-8 range. >> I would oppose an epoch of 2. > > I can live with that, though it might mean th

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 12:14 PM, Matt Caswell wrote: > > I support Richard's proposal with an epoch of 1. > Grudgingly I would accept an epoch in the 3-8 range. > I would oppose an epoch of 2. I can live with that, though it might mean that a minority of applications will interpret (based on o

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On 21/09/18 17:04, Viktor Dukhovni wrote: > I think I've said everything I have to say on this topic. So I'll stop > for now. I continue to support Richard's proposal, but with an epoch > smaller than 8. > To summarise my position: I support Richard's proposal with an epoch of 1. Grudgingly

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 11:56 AM, Tim Hudson wrote: > > What I was suggesting is that we don't need to break the current encoding at > all. Not changing the encoding has a downside. * The bits that represent ABI stability would shift from the 2nd/3rd nibbles to just the first nibble. * We

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On Sat, Sep 22, 2018 at 1:39 AM Viktor Dukhovni wrote: > The only change needed is a minor one in applications that actually > parse the nibbles What I was suggesting is that we don't need to break the current encoding at all. We have a major.minor.fix version encoded and documented in the heade

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 11:40 AM, Tim Hudson wrote: > > That is something I wouldn't suggest makes sense as an approach - to change > the tarfile name and leave all the internals the same achieves nothing. And that's not the proposal. The proposal is that the new major number is 2 (or 3 if so

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On Sat, Sep 22, 2018 at 1:34 AM Matthias St. Pierre < matthias.st.pie...@ncp-e.com> wrote: > > On 21.09.2018 17:27, Tim Hudson wrote: > > > > We cannot remove the current major version number - as that concept > exists and we have used it all along. > > We don't just get to tell our users for the

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 11:27 AM, Tim Hudson wrote: > > No it isn't - as you note that isn't a valid mapping - 1.0 isn't a semantic > version and there is no such thing as a fix number, > You get three concepts and then on top of that the pre-release and the > build-metadata. > > Semantic ver

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On 21.09.2018 17:27, Tim Hudson wrote: > > We cannot remove the current major version number - as that concept exists > and we have used it all along.  > We don't just get to tell our users for the last 20+ years what we called the > major version (which was 0 for the first half and 1 for the se

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On Sat, Sep 22, 2018 at 1:16 AM Viktor Dukhovni wrote: > > > > On Sep 21, 2018, at 11:00 AM, Tim Hudson wrote: > > > > If you repeat that in semantic versioning concepts just using the labels > for mapping you get: > > - what is the major version number - the answer is clearly "1". > > - what is

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 11:16 AM, Viktor Dukhovni > wrote: > > I'm afraid that's where you're simply wrong. Ever since 1.0.0, OpenSSL > has promised (and I think delivered) ABI stability for the *minor* version > and feature stability (bug fixes only) for the patch letters. Therefore, > the s

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 11:13 AM, Matthias St. Pierre > wrote: > > I like Richard's approach (with the '8' or another number) and I don't think > it is > contradicting semantic versioning. Maybe a good compromise between your two > opposing views would be to make the encoding irrelevant to o

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 11:00 AM, Tim Hudson wrote: > > If you repeat that in semantic versioning concepts just using the labels for > mapping you get: > - what is the major version number - the answer is clearly "1". > - what is the minor version number - the answer is clearly "0" > - what is

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

I like Richard's approach (with the '8' or another number) and  I don't think it is contradicting semantic versioning. Maybe a good compromise between  your two opposing views would be to make the encoding irrelevant to our users by introducing version check macros like        OPENSSL_MAKE_VERS

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On Sat, Sep 22, 2018 at 12:32 AM Viktor Dukhovni wrote: > > On Sep 21, 2018, at 10:07 AM, Tim Hudson wrote: > > > > And the output you get: > > > > 0x10102000 > > The trouble is that existing software expects to potential ABI changes > resulting from changes in the 2nd and 3rd nibbles, and if th

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 10:07 AM, Tim Hudson wrote: > > And the output you get: > > 0x10102000 The trouble is that existing software expects to potential ABI changes resulting from changes in the 2nd and 3rd nibbles, and if the major version is just in the first nibble, our minor version chan

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

I think we have to keep OPENSSL_VERSON_NUMBER and it has to have MAJOR.MINOR.FIX in it encoded as we currently have it (where FIX is PATCH in semantic terms and our current alpha PATCH is left blank). That is what I've been saying in the various emails - because we precisely need to not change the

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

> On Sep 21, 2018, at 9:35 AM, Richard Levitte wrote: > > In that case, we should probably just thrown away > OPENSSL_VERSION_NUMBER. Sorry, that must not t happen and there's no need. My sense is that Tim may end up "in the rough" on this issue, so unless there's more evidence of support for

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

I support Richard's numeric scheme as proposed, with one small change. I think that setting the epoch to 8 to set the high bit is neither necessary nor wise. Though the numeric version constant should be manifestly unsigned (UL suffix not L), and having the top 3 nibbles for the "effective" major

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

In message on Fri, 21 Sep 2018 23:01:03 +1000, Tim Hudson said: > Semantic versioning is about a consistent concept of version handling. > > And that concept of consistency should be in a forms of the version > - be it text string or numberic. > > That you see them as two somewhat independent

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

Now I get the conceptual issue that Richard and Matt are differing on - and it is about actually replacing OpenSSL's versioning concept with semantic versioning compared to adopting semantic versioning principles without actually being precisely a semantic version approach. The whole concept of se

[openssl-project] Release strategy updates

I am very concerned about stability of our API moving forwards. There are various discussions about changing the version number to 1.2.0 (or possibly 2.0.0) - which according to our versioning scheme would allow breaking changes. Whilst this is true I think we need to be very wary about "opening th

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

In message on Fri, 21 Sep 2018 21:28:55 +1000, Tim Hudson said: > So as a concrete example - taking master and the current OPENSSL_VERSION_TEXT > value. > > "OpenSSL 1.1.2-dev xx XXX " > > would become > > "1.1.2-dev+xx.XXX." No, it would become "1.1.2-dev" I have no idea why you

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On 21/09/18 14:01, Tim Hudson wrote: > Semantic versioning is about a consistent concept of version handling. > > And that concept of consistency should be in a forms of the version - be > it text string or numberic. > > That you see them as two somewhat independent concepts isn't something I

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On 21/09/18 13:52, Richard Levitte wrote: > Note that this is for the text form, which is separate from our > numeric encoding (something that isn't covered by semver at all). > That is the only place where I propose to have an epoch, and it's for > one purpose only, that the value of that numbe

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

In message on Fri, 21 Sep 2018 21:17:12 +1000, Tim Hudson said: > i.e. OPENSSL_VERSION_NUMBER should be X.Y.Z So you mean we'd lose the integer form entirely? Hey, I have zero issue with that! However, that's going to make life hard for everyone that wants to be able to build against differe

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

Semantic versioning is about a consistent concept of version handling. And that concept of consistency should be in a forms of the version - be it text string or numberic. That you see them as two somewhat independent concepts isn't something I support or thing makes sense at all. Our users code

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

In message on Fri, 21 Sep 2018 20:48:34 +1000, Tim Hudson said: > On Fri, Sep 21, 2018 at 7:58 PM Richard Levitte wrote: > > Our FAQ says that such changes *may* be part of a major > release (we don't guarantee that breaking changes won't happen), while > semantic versioning says that majo

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

So as a concrete example - taking master and the current OPENSSL_VERSION_TEXT value. "OpenSSL 1.1.2-dev xx XXX " would become "1.1.2-dev+xx.XXX." That is what I understand is the point of semantic versioning. You know how to pull apart the version string. -dev indicates a pre-release v

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On Fri, Sep 21, 2018 at 9:02 PM Matt Caswell wrote: > I think this is an incorrect interpretation of Richard's proposal. The > OPENSSL_VERSION_NUMBER value is an *integer* value. It does not and > cannot ever conform to semantic versioning because, because version > numbers in that scheme are *st

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On 21/09/18 11:48, Tim Hudson wrote: > On Fri, Sep 21, 2018 at 7:58 PM Richard Levitte > wrote: > > Our FAQ says that such changes *may* be part of a major > release (we don't guarantee that breaking changes won't happen), while > semantic versioning says

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

On Fri, Sep 21, 2018 at 7:58 PM Richard Levitte wrote: > Our FAQ says that such changes *may* be part of a major > release (we don't guarantee that breaking changes won't happen), while > semantic versioning says that major releases *do* incur backward > incompatible API changes. > I think you a

[openssl-project] A proposal for an updated OpenSSL version scheme (v2)

Hi, I've worked on a proposal for an update of the OpenSSL version scheme, to basically align ourselves with semantic versioning, most of all in presentation, but also in spirit, while retaining numeric compatibility. This proposal is currently in the form of a Google Document: https://docs.goog