apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guenter Knauf <fua...@apache.org>
Subject Re: apr-util 1.5.x -> trunk
Date Wed, 06 Oct 2010 23:46:38 GMT
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).





Mime
View raw message