
Gottlob Frege wrote:
//svn.boost.org/svn/boost/
trunk
tags/ ... releases/ ... 1_34_1 1_35_0
branches/ release libs/ ... python serialization ...
Assuming this is the latest proposal, maybe an outside opinion of an idiot user (ie me) might help?
Yes, for sure. User perspectives balance the developer perspectives.
P.S. I'm NOT a SVN user (Perforce for me, thanks).
Without reading Beman's doc (and outside users probably won't) nor most of these emails, this is my first impression:
- 'tags/releases' is where past releases are - excellent
Yep. And I've updated the trac page to reflect Dave's suggestion that it be "releases" with an "s" rather than "release".
- 'branches' is where unstable development is happening (but really, I cheated - I read the emails to determine that for sure - because 'branches' can also mean released items, like a fork of boost or something like that, or maybe someday boost 2.0 (only supports C++0x) is released and boost 1.40 (old code base) is also released - these would be two 'branches' of boost)
The "branches" name is traditional with CVS and SVN users for where unstable development is happening, so I don't think there is much potential for confusion there, except perhaps for those with no CVS or SVN exposure.
- trunk or branches/release is where the 'latest stable but not yet released boost' (ie the one I might experiment with to see what's coming) lives. Which is it? ie which is the 'release_candidate'?
Basically, I'd like words like - 'released' (note the 'd') - 'in_progress' - 'release_candidate'
or similar. But maybe that's just because I don't use SVN.
Hum... "branches/release_candidate" would certainly be more explicit than "branches/release". It is longer, but an SVN user doesn't actually have to type the name very often, so I'm not inclined to worry about that. Anyone else care to hazard an opinion on "branches/release_candidate" vs "branches/release"?
And sorry to bring naming back up as a topic. Feel free to move on to other things (ie just get started), but I always find a 'first impression' is worthwhile (and only comes once).
I don't mean to cut off repository organization and naming discussion prematurely. I do, however, want to make sure we don't stall on those topics while there are other decisions that need to be made. And, yes, "first impression" are very valuable. Thanks, --Beman