On Wed, Aug 12, 2015 at 1:29 PM, Mark Kettenis wrote:
>> Date: Tue, 11 Aug 2015 09:15:43 -0600
>> From: Bob Beck
>>
>> I'm wondering out loud if these versions should follow the openbsd shlib
>> major minor numbers. That is where we are careful about semantic
>> versioning for api change/add/rem
> On occasion we make API changes which don't meet those bars, but they
> are rare. And since we have these libraries "linked together", we
> try to be more cautious, and agressive cranking is already the norm
>
> It might work out.
That's why I'm thinking along these lines
Jan Engelhardt wrote:
>
> On Wednesday 2015-08-12 20:29, Mark Kettenis wrote:
> >
> >One possible reason to deviate from using the LibreSSL release version
> >would be if we want to continue to be a drop-in replacement for
> >OpenSSL. In that case continuing to adevrtise a reasonable OpenSSL
> >v
> On Wednesday 2015-08-12 20:29, Mark Kettenis wrote:
> >One possible reason to deviate from using the LibreSSL release version
> >would be if we want to continue to be a drop-in replacement for
> >OpenSSL. In that case continuing to adevrtise a reasonable OpenSSL
> >version number for openssl.pc,
On Wednesday 2015-08-12 20:29, Mark Kettenis wrote:
>
>One possible reason to deviate from using the LibreSSL release version
>would be if we want to continue to be a drop-in replacement for
>OpenSSL. In that case continuing to adevrtise a reasonable OpenSSL
>version number for openssl.pc, libcry
On Wed, Aug 12, 2015 at 08:29:09PM +0200, Mark Kettenis wrote:
> > Date: Tue, 11 Aug 2015 09:15:43 -0600
> > From: Bob Beck
> >
> > I'm wondering out loud if these versions should follow the openbsd shlib
> > major minor numbers. That is where we are careful about semantic
> > versioning for api
> Date: Tue, 11 Aug 2015 09:15:43 -0600
> From: Bob Beck
>
> I'm wondering out loud if these versions should follow the openbsd shlib
> major minor numbers. That is where we are careful about semantic
> versioning for api change/add/remove
No. Shared library versions are tracking the ABI. What
On Tuesday 2015-08-11 03:39, Brent Cook wrote:
>
>> So I think all the .pc files in LibreSSL should simply use the LibreSSL
>> version number (2.2.2) like the openssl.pc does. This does mean that
>> checking
>> for individual libraries in LibreSSL version 2.2.2 and older will probably
>> busted,
Indeed. It would mean we need to be careful. But I think us being careful
here is the least worst alternative.
We also (if we absolutely had to) could bump the minor ahead of base and
catch up or pass it again once possible. But I think for the most part our
changes will mirror base anyway
On Tue
> Yes. I suppose it comes down to can we crank the minor for a portable
> release if it had not been
We could, for about 10 months of the year. For 2 months of the year, this
is difficult. I am not rejecting the idea, but making sure you think about
it.
Yes. I suppose it comes down to can we crank the minor for a portable
release if it had not been
On Tuesday, August 11, 2015, Theo de Raadt wrote:
> But it also means if a new LibreSSL release is going to go out, and there
> hasn't been an ABI crank
>
> > That's actually the point. Because w
But it also means if a new LibreSSL release is going to go out, and there
hasn't been an ABI crank
> That's actually the point. Because while released releases might, if anyone
> is testing snapshot portable builds from github they might not. And still
> don't get fucked.
>
> On Tuesday, Augu
I mean we know we do this right in openbsd. It doesn't make sense to me to
hope the bundlers out there do in a vacuum. Sure they will still fuck up.
But at least this way the horse is properly lead to water
On Tuesday, August 11, 2015, Bob Beck wrote:
> That's actually the point. Because while
That's actually the point. Because while released releases might, if anyone
is testing snapshot portable builds from github they might not. And still
don't get fucked.
On Tuesday, August 11, 2015, Theo de Raadt wrote:
> > I'm wondering out loud if these versions should follow the openbsd shlib
>
> I'm wondering out loud if these versions should follow the openbsd shlib
> major minor numbers. That is where we are careful about semantic
> versioning for api change/add/remove
One note.
If that is decided, on occasion libressl-portable could skip a release
number. Probably fine for everyon
I'm wondering out loud if these versions should follow the openbsd shlib
major minor numbers. That is where we are careful about semantic
versioning for api change/add/remove
On Monday, August 10, 2015, Brent Cook wrote:
> On Mon, Aug 10, 2015 at 5:10 AM, Mark Kettenis > wrote:
> > Jan Engelha
On Mon, Aug 10, 2015 at 5:10 AM, Mark Kettenis wrote:
> Jan Engelhardt schreef op 2015-08-10 10:29:
>
>> On Monday 2015-08-10 02:38, Brent Cook wrote:
On Aug 9, 2015, at 10:07 AM, Jan Engelhardt wrote:
> We have released LibreSSL 2.2.2, which will be arriving in the
> Libre
Jan Engelhardt schreef op 2015-08-10 10:29:
On Monday 2015-08-10 02:38, Brent Cook wrote:
On Aug 9, 2015, at 10:07 AM, Jan Engelhardt wrote:
We have released LibreSSL 2.2.2, which will be arriving in the
LibreSSL directory of your local OpenBSD mirror soon.
The .pc files in libressl-2.2.2 u
On Monday 2015-08-10 02:38, Brent Cook wrote:
>> On Aug 9, 2015, at 10:07 AM, Jan Engelhardt wrote:
>>
>>> We have released LibreSSL 2.2.2, which will be arriving in the
>>> LibreSSL directory of your local OpenBSD mirror soon.
>>
>> The .pc files in libressl-2.2.2 upset the package mechanisms
> On Aug 9, 2015, at 10:07 AM, Jan Engelhardt wrote:
>
>> We have released LibreSSL 2.2.2, which will be arriving in the
>> LibreSSL directory of your local OpenBSD mirror soon.
>
> The .pc files in libressl-2.2.2 upset the package mechanisms at hand, in
> particular rpm, where ':' is used to
>We have released LibreSSL 2.2.2, which will be arriving in the
>LibreSSL directory of your local OpenBSD mirror soon.
The .pc files in libressl-2.2.2 upset the package mechanisms at hand, in
particular rpm, where ':' is used to denote the (ancient concept of)
epochs.
[ 99s] Invalid versi
21 matches
Mail list logo
