Am 06.10.2010 18:20, schrieb Joe Orton:
1) The tip of development for the apr-util tree is what is currently
branches/1.5.x. Yes, most of that code also exists in the apr tree.
apr-util releases and branches do not come from the apr tree, they come
from the apr-util tree.
but here's the whole in the shoe: currently we have not yet considered
APU 1.4.x ready to rock, thus we do stupid copy-over form APU 1.5.x to
APU 1.4.x for no real benefit - the APU releases come from APU 1.3.x.
2) I have hard-coded into my brain the convention that the trunk is the
trunk, not a branch named by its current version. I also have scripts
which make this assumption.
well, thats bad then since we have a trunk in each branch, so your
hard-coded wires do probably anyway not fit to the model we have in SVN.
I had also a bunch of scripts which I did already chane, not to mention
the merge of 2.0 APR/APU. To me the whole terminology of trunk sucks:
internally I have re-wrired to the model of what SVN calls it: HEAD =
2.0. But this doesnt any better, but just only another name; then again
one can argue that each branch has its HEAD ...
Anyway, regardless how we name it, and regardless if you rename 1.5.x to
tunk or not - it doesnt save ud from stupid copying between the
branches. But what would save us from this would be if we simply would
delete either the 1.4.x or 1.5.x APU branch - isnt that something to
consider? Also, wouldnt it be worth to consider some rework on the
versioning system? Perhaps we should introduce something like APR_API /
APU_API, and bumb these every time new functions get added, and so
APR/APU consumers could easily check if the version found meets
requirements rather than rely completely on version numbers.
3) The trunk called branches/1.5.x will have to be renamed to a trunk
called branches/1.6.x if 1.5.x gets cut. Which is dumb.
4) Yes, "people" might get confused if they try to use apr-util's trunk
with the APR 2.x, but, meh. We are the people who use the VCS and it
should be arranged for our convenience.
well, recent changes are hard to understand for lib consumers, and
confusing: for almost a decade we have had coupled version numbers for
APR/APU, and just now we have started to have two different branches of
APR/APU with APR 1.4.x and APU 1.3.x releases ...
I think we should kill one branch again: like you say development
happens in 1.5.x, so probably we should then delete APU 1.4.x, copy over
APU 1.3.x -> 1.4.x, and bring branch 1.3.x completely to bed, no?
Maybe I have not thought about all details regarding API, so forgive -
its just what I was thinking the last days when your suggestion came up ...
my 3 ct.
Gün.
BTW. there also seems to be other ways how to deal with different
branches in SVN, f.e. PHP has such a system with IIRC sparse checkout
where you have all branches in one tree together, and can make changes
to all branches simultanously (as I said IIRC).
