> Sorry if this is long-winded: Dito :)
> One reason is that incrementing for sub-minor versions in the CVS source > doesn’t mean anything, since the portable release schedule is independent in > OpenBSD land. Agreed that this doesn't make much sense for CVS source, for the -portable tarballs however it would. > A second reason is to prevent software from using the version number or string > to test for features, which has been frequently misused and abused. Have strings really been misused this way? Yikes... > The presence of a string or version number in a header or program is mostly > random. > > A third reason is, its redundant. How do you check what versions you are using > of all other packages that don’t ship with headers or have version flags? > Everything would be different. > > Luckily, there is a method that works for all software: your OS’s package > manager! (you are using packages for production, right? not ‘make install’ > into > /usr/local on servers?) I get your point, but I don't believe its always that simple. Should we really exclusively care about users of the packaging systems provided by the OS, nobody else? Enterprise users may do their own packaging (of specific application using libssl), commercial software may comes as a binary package, both linked against shared libssl. The embedded sector may has similar use cases. Having no idea what libssl/lilbcrypto release the application was build against is not very pleasant when you have to troubleshoot strange problems or crahes and in the end the simple reason is that there is no ABI or even API compatibility between the library the application was build against and the library that is actually running. This is why haproxy -vv shows both build and runtime release [1]. Not to affect code paths (at least in this instance), but to inform. > incrementing for sub-minor versions While we are talking "sub-minor" on the portable site, in cvs we are talking "major" [2,3], so perhaps we are looking at this from the wrong angle: should we really only increment the portable releases on a sub-minor level given the actual ABI/API changes across those releases? Will the portable tree or libressl in general ever get any ABI/API stability, or is it simply to soon to talk about those things and we should let it settle some more? > Though I’m not 100% opposed to some sort of post-processing addition to the > portable tree that could fiddle with that overarching version string as it > is embedded into openssl(1) I agree, that would work. Regards, Lukas [1] http://www.haproxy.org/git?p=haproxy.git;a=commitdiff;h=0cff0dbfc0813d01a0ebbd3910519bfac4d9eec2 [2] https://github.com/libressl-portable/openbsd/commit/c8d18f00f5cf5881d979b0ecbdf0ae73f8184865 [3] https://github.com/libressl-portable/openbsd/commit/52a59f2208d380d4c49c4c3d6866766bad13f4b4
