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

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.

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

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

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

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.

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

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

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

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

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

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

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

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       

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

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

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

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"

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

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

[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

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

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

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

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

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

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

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

[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: