Justin Erenkrantz wrote:
The only apparent change to the end-user is that there would be no 1.3.x,
and the next release they are told to obtain is 1.4.x or later.
The problem is that all of the downstream users have to change their
own compatibility rules to adjust for us reneging on our release
policies. Serf and Subversion would have to be substantially tweaked
to adjust for this as all of APR's versioning policies get thrown out
the window as the version tag is no longer usable.
Now hold up.
Serf and Subversion would be VERY ILL ADVISED to ship based on the
floating target. They too would be constrained to an alpha/beta.
In fact, I'd suggest that anyone trying this would want to mark their
package as depending on exactly n.x.y. Not on n.x minimum. They too
would be alpha/beta if they relied on a alpha/beta apr.
[And I really liked Lucian's point, especially if we were to cripple
make install to NEVER NEVER deploy the apr-n.so symlink! But that
is another issue to consider altogether, also have the issue of
includes.]
The only sane prerequisite would be 1.2... or 1.4. None of this
'maybe something from 1.3.2 fowards'. No - if it's using a feature
of 1.3, they need to release for 1.4.0 forwards. (Of course we would
be breaking it to their desire until 1.4.0 is blessed.)
So your argument doesn't hold water, you need to be more specific.
FWIW ONLY THE 1.3.x changes would be mutable in 1.3.x!!!
I don't think you fully appreciate what impact this change has on
consumers of APR.
I do. People who adopt alpha/beta of such a library aren't end users,
or to the extent they are, no harm, no foul, because nothing is asking
for 1.3.2 minimum.
Yes we would need to clear this up in the versioning rules, but I'm
just not seeing a showstopper here.
Either release a 1.3.0-dev snapshot or move trunk to 2.0.0-dev if you
think the APIs change substantially and need feedback. However, in my
opinion, under no circumstances should we *ever* release a 1.3.1 that
isn't compatible with 1.3.0 per the current versioning rules. We
committed to those rules and we need to stick to them. The only
avenue for changing them is when we go to 2.0 - and even then, I'm not
sure I'd support such a change anyway; but at least then, we could
entertain that discussion. -- justin
We won't call it 2.0 for the sake of 'taking this for a whirl'. But
we are getting close, I'm looking at some pretty crappy function names
these past few weeks.
lib_module_noun_verb
how hard is that anyways?
Bill
