Victor Mote wrote:
Clay Leeds wrote:
Perhaps it was laziness (ouch! ;-p), but I'd like to think not. I spent 10-15 minutes looking on the site to determine where I could download the the 1.0Dev version to test with--actually, I've gone searching a *bunch* of times, only to get frustrated and "come back later" to find it. Truth is, I didn't know *what* to look for and the term "snapshot" didn't come to mind...
Anyway, I will be submitting a [PATCH] to change the download page to highlight "FOP 1.0DR1 Snapshot" shortly. However, I might also modify the page to indicate the following links/headings:
* Binary or Source? * Current Release Binary Download * Current and Development Release Source Downloads
I'll then change the content of the "Current and Development Release Source Downloads" section accordingly:
<snip/>
MODIFIED: * [b]FOP-1.0DR1 Snapshot[/b] - Download a CVS snapshot of FOP-1_0DR1 from the cvs files [a href=..]here[/a]. These snapshots are built approximately every six hours, and have the GMT of their creation time embedded in their names. Please note that these CVS snapshots are made only for the "HEAD" branch.
* [b]FOP-1.0DR1 Snapshot[/b] - Download a CVS snapshot of FOP-1_0DR1 from the cvs files [a href=..]here[/a]. These snapshots are built approximately every six hours, and have the GMT of their creation time embedded in their names. Please note that these CVS snapshots are made only for the "HEAD" branch.
* [b]FOP-1.0DR1 Snapshot[/b] - Download a CVS snapshot of FOP-1_0DR1 from the cvs files [a href=..]here[/a]. These snapshots are built approximately every six hours, and have the GMT of their creation time embedded in their names. Please note that these CVS snapshots are made only for the "HEAD" branch of [a href="http://cvs.apache.org/viewcvs.cgi/xml-fop/ ?only_with_tag=HEAD"]CVS[/a].
I'd also like to standardize on what we'll be calling this on the site. Here are the contestants I'm aware of:
Redesign TRUNK
+1
HEAD FOP 1.0Dev FOP-1.0Dev FOP1.0Dev FOP 1.0DR1 FOP-1.0DR1 FOP1.0DR1
(Personally, I like "FOP-1.0DR1" so that's what I'll use in my [PATCH]. I'm not calling for a vote--a) I don't think I can call a VOTE yet; b) does this need a VOTE?--but it would be good to know that everyone's on the same page... ;-p)
The term "Redesign" will become obsolete as soon as 1.0 gets released.
(FYI: "FOP-1.0Dev" turns up on the command line as version indicator )
Obsolescence. Too true! Hehehe! Anyway, I thought I'd seen FOP-1.0Dev somewhere!
On the naming issue, I think it is worth distinguishing between 1) branch names, 2) tags for those branches, and 3) version IDs. What we are really naming here is a branch, and the tags and versions should not be confused with it. Our "maintenance" branch is tagged "fop-0_20_2-maintain" from which we get version 0.20.5. Within CVS, the trunk branch is tagged "HEAD" from which we have no current versions. Of the choices given, only "trunk" and "head" make any sense to me. I have a very strong dislike for naming it 1.0_anything or any other transitory name like "redesign". (I have no problem with using these terms as we have, but dislike them as permanent names). I especially dislike 1.0_anything as I don't have any reason to think that we are working on 1.0 yet.
HEAD is the default in CVS. It is probably worth noting this in any user documentation. As HEAD will be with us for as long as we use CVS, it makes sense to me, while we are talking about reducing naming confusion, to use HEAD as much as possible, with notes to the effect that HEAD is the unstable/unusable (depending on requirements and the current state of HEAD) development branch, while the stable releases come from the fop-0_20_2-maintain branch. This name is plainly misleading, but, as no further major development on the branch, it is probably not worth the effort to fix this.
(If it were considered worthwhile, the simplest way would probably be to create a branch off fop-0_20_2-maintain, say fop-0_20-maintenance (or FOP_0-20_maintenance). Because all access to previous releases and release candidates should be by release tag, rather than branch tag, the fop-0_20_2-maintain tag would fade into the background, even though it is still the basis of all earlier post 0.20.2 releases.)
We can't create a *branch* FOP_1-0_Dev or whatever, because, AFAIK, as soon as you try to create a branch rooted at HEAD, you spin of a new branch, while HEAD goes merrily on its way.
On the other hand, it is easy and essential to tag the tree at any point of interest. All of our release candidates and releases should be able to be reconstituted from a given tag.
HEAD snapshots can be indicated by a date-time specifier, because they can be reconstituted from the tree using that date-time marker. This requires a little developer discipline. If we advise users that the tree will be update stable at a certain time, say, 00:00 GMT, developers should not perform a series of checkins across that time. (Although this is not, strictly speaking, essential.)
Then there is no need for us to actually construct development snapshots. The build process is not onerous, and it doesn't take 12 hours to build. If users are told to checkout development builds from the tree using a -D specifier with 00:00 GMT time, we can always get back to the same source tree in the event of some non-reproducible bug being reporting by a HEAD user.
There are a few issues with sticky date specifiers, which we will have to work out and document for users. Basically, we need a formula for getting from one -D checkout to another with the minimum of anguish.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
