[Different discussion, switching thread subjects] Guenter Knauf wrote: > I think we need a way to distribute alpha releases, just same as what we > do with httpd.
+1; That was a serious omission in our versioning policy. I raised the same question a long time back, and was basically told "not a consideration", see the archives. If memory serves, Greg was the first to forcefully respond that there isn't such a mechanism, by-design. > Now what I'm trying to understand is how we really break machines of > alpha testers? I guess I don't understand your comments in the context of this discussion. People test alpha and beta candidates all the time, ultimately in context of a development machine deployment, staging server, etc etc. It's called living on the bleeding edge. > Second how do we break things, and what do we break? > The installed libraries are most likely not a problem since they have a > new so name, so nothing links against them. So are you addressing alpha-/beta- of new major revs only? Not minor revisions, e.g. a 2.1.0-alpha? > The installed headers are > more a problem, and we should think of a way to workaround this. Isnt it > possible to use versioned directories like 'apr-1.4' instead of just > 'apr'? Then we could probably have more than one installed apr version > side by side ... That implies we should simply dissolve our versioning contract, something I'd already considered putting up for a vote. But we typically change things incrementally; this is where I'm attempting to redirect the spirit of disagreement into productive dialog about what should change. > Another thing could be to default to static libraries, and only build > shared ones if explicitly specified as argument to configure ... Possible, but necessary? Or are you speaking only with reference to such alpha- and beta- candidates? And do people end up with a static apr linked to static crypto, that wouldn't pick up security patches such as the current TLS protocol rework?
