Re: cvs: pear /HTTP HTTP.php package.xml

[Jon Parise <jon@php.net>] > On Fri, Aug 03, 2001 at 08:30:15AM -0000, Stig Bakken wrote: > > > ssb Fri Aug 3 04:30:15 2001 EDT > > > > Modified files: > > /pear/HTTP HTTP.php package.xml > > Log: > > * preparing a "real" 1.0 release (tagging with V_1_0_RELEASE) > > Is that how we're going to tag "stable" PEAR release? > > I think the best way is simply to tag the package with the > version number (e.g. V_1_0) and then add additional, mobile > tags named 'RELEASE' or 'DEVELOPMENT'. Or would too many people > find that too complicated? What would the purpose of the version tag be? A branch for micro-releases? Here's what I have in mind (dropping the V_ for now): RELEASE_1_2 Simple tag that can be used to check out the package in the state it was when {version} was released. It should not move. QA_1_2 Branch. Like PHP's release candidate branches, this branch is used to prepare a release, only critical bug fixes go here. Most people will not need this one I guess. MAINT_1_2 Branch. Let's say you fix some bad bugs in 1.2 and want to release 1.2.1 quickly, but there are some changes on the main trunk that have not been well enough tested. Make a MAINT_1_2 branch from RELEASE_1_2, commit the fix there and tag/release RELEASE_1_2_1 from the branch. Probably only needed for bigger packages with many developers. DEV_feature Branch for developing "feature" without interfering with the main trunk. RELEASE is the only one we need to require, the others could serve as recommendations. There's a whole bunch of other tags that may be useful when dealing with branches, but it gets a bit too specific for a tagging scheme like ours. - Stig