commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [pool] trunk?
Date Tue, 29 Jan 2008 13:51:19 GMT
I would prefer to see trunk used for the main development, and
branches for experimental stuff, but of course this changes over time.

What is important is that the currently active branch(es) and trunk
are cleary documented on the web-site and in SVN - I've seen a STATUS
file used for this, or perhaps a REAME.
This file needs to be at the top-level of trunk (and the contents
should indicate that the latest version is always in trunk)

For a long while in JMeter the trunk was not where the main dev was
taking place, and this caused quite a few problems (as it was also not
well documented ...).

S///
On 29/01/2008, Gary Gregory <GGregory@seagullsoftware.com> wrote:
> It seems to me that once a release is out, it should be in a branch for maintenance,
so we would have v1.4 in a branch that would source 1.4.x releases. The trunk is for the next
release 1.5 or 2.0. This allows for just tiny well placed changes for bug fixes in 1.4 as
1.4.x releases. IMO, other (major) changes should only happen in the context of a major (2.0)
or minor (1.5) release and are appropriate in trunk. Once the scope of the next release(s)
is decided, then you can decide whether you create a branch for 1.5. IMO, the trunk is for
the current high tech work, compatible or not and branches for more targeted and well-defined
goals.
>
> Thank you,
> Gary
>
> > -----Original Message-----
> > From: Phil Steitz [mailto:phil.steitz@gmail.com]
> > Sent: Monday, January 28, 2008 7:00 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [pool] trunk?
> >
> > Any other opinions on this?
> >
> > I want to clean this up.  Backporting all of the changes in the 1.4
> > release branch will break some things in trunk, since the composite
> > package uses the new contracts with incompatible changes.  So I would
> > like to do the following, which I am not sure how to do in svn, so
> > would appreciate feedback.
> >
> > 1) move current trunk to a 2.0 branch
> > 2) essentially copy 1.4 release branch to trunk, retaining history
> >
> > The idea here is that what is now in trunk should have been branched
> > as 2.0.  I could use merge to backport changes after moving only the
> > composite package out, but this would mess up history on the 1.4
> > sources.  I am not sure what the best way to accomplish 2) is and
> > would appreciate comments.
> >
> > Alternatively, I could copy the 1.4 release to a "1.x" branch and
> > leave trunk alone, temporarily dead.  That would be the easiest, but
> > does not seem right.
> >
> > Thanks in advance for feedback.
> >
> > Phil
> >
> > On Jan 17, 2008 10:12 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
> > > On Jan 16, 2008 11:18 PM, Henri Yandell <flamefew@gmail.com> wrote:
> > > > Is development back on trunk yet?
> > > >
> > > > Having it off on a branch worries me :)
> > > >
> > >
> > > We need to make a decision on the 1.3/1.4-incompatible changes that
> > > are currently in trunk, which should probably iteself have been
> > > branched as 2.0.
> > >
> > > My preference is to move the composite package to a composite or 2.0
> > > branch and merge the 1.4 release branch back into trunk, reverting the
> > > incompatible changes as in 1.4.
> > >
> > > Phil
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message