On Thu, 2006-02-23 at 18:55 +1300, Simon Kitching wrote:
> On Wed, 2006-02-22 at 22:48 +0000, robert burrell donkin wrote:
> > On Wed, 2006-02-22 at 18:32 +1300, Simon Kitching wrote: 
> > > On Tue, 2006-02-21 at 21:46 +0000, robert burrell donkin wrote:
> > > > I've cut a branch for any ongoing work needed for JCl1:
> > > > http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/branches/JCL1/
> > > > 
> > > > future release candidates will be cut from this branch.
> > > 
> > > I think that a JCL 2.x series would best be served by starting with a
> > > completely fresh directory anyway; the code will be quite different.
> > 
> > a separate top level directory or another branch? 
> 
> With SVN, there's no difference :-)

i meant top level as in proper/commons-logging2 but i think it's clear
that the answer to this is no...
 
> > > So perhaps we could instead remove the JCL1 branch, and run JCL1.x from
> > > trunk for the moment while JCL2.x is a separate dir? Later we could
> > > rename trunk to JCL1 while JCL2 is renamed to "trunk"...
> > 
> > i think i'm happier using a branch for the release: less risk that way
> > but feel free to start JCL2 off on a branch.
> > 
> > > Please let me know as I have currently committed the AvalonLogger change
> > > (intended for the 1.x series) to trunk only..
> > 
> > yep (noticed the commit)
> > 
> > not a problem (or at least, an easy problem to sort out). i'll patch the
> > release branch.
> 
> It still feels a bit weird to me to have a 1.1 release branch. What
> could possibly be committed to trunk that would not be wanted in the 1.1
> branch? What could possibly be committed to the 1.1 branch that would
> not be wanted in trunk?
> 
> And if (as I believe) the answer to the above is "nothing", then why
> have a branch? Either everything gets committed twice or trunk will get
> out-of-date which will just confuse everybody.

it's really about control. a release branch is the domain of the release
manager and i'd expect to make the majority of the commits.  

> I guess the only bits might be the kind of "global maven cleanups" that
> occasionally occur.

anything like that

it's probably going to take a while to get the code verified (whether
it's named as a release candidate or as an alpha). seems like the
release vote will need more time (or will fail from lack of interest).
so, i don't think that we'll actually be shipping JCL1.1 for a while
yet...

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to