Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.212.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=IChtkj/Z+q3MAW9wmjRs+HAXvcGj7HqiFnnVAz3Z8Q1ttwypSumcOx+BeF6dKAq71X
         tVbYWiAqRfAvkvTNx3CQvx+FZ/dJfJK6LbPjGOVakfhyul8LpT5XVcRFUPiS7mM5Z0OY
         C8Yf0e+BbAJNQNmpDV9A5wT0LMIk5MGdRzNrE=
Message-ID: <4D9E253A.3070509@gmail.com>
Date: Thu, 07 Apr 2011 13:57:30 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [lang] alpha package
References: <BANLkTincaApAQAxvRr55anWkK8B8tkTsJA@mail.gmail.com>
	<BANLkTinFy+yaDWY1BwUsnum9ppmew=bZfw@mail.gmail.com>
	<BANLkTi=CqW-hD6a_QTYvkLm_DZVC_9K-dg@mail.gmail.com>
	<BANLkTinu9BEEfk9czHWdjg_8UxaLKTw0_Q@mail.gmail.com>
	<BANLkTi=TPDSQt6gM3YpmizyNAxOHFz6XBA@mail.gmail.com>
	<BANLkTimaCTuOBg4dXhQiSqvVBO25sD4hfw@mail.gmail.com>
	<4D9DF8D3.3020003@gmail.com>
	<BANLkTinnO=JXqemga-5s0kBRrN8MC7Z1sw@mail.gmail.com>
 <BANLkTi=-43EiV3CLgR+yHrbkw1FKNVsCRQ@mail.gmail.com>
In-Reply-To: <BANLkTi=-43EiV3CLgR+yHrbkw1FKNVsCRQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 4/7/11 1:14 PM, sebb wrote:
> On 7 April 2011 21:08, Henri Yandell <flamefew@gmail.com> wrote:
>> On Thu, Apr 7, 2011 at 10:48 AM, Phil Steitz <phil.steitz@gmail.com> wrote:
>>> I think the idea of having a separate, releasable "child" of some
>>> kind that can break compatibility with its parent and earlier
>>> versions of itself is a good one.  The setup I have described above
>>> is probably not the best, but we should be able to figure out how to
>>> do it and communicate what it means to users.  Letting the child
>>> keep living with the parent makes me nervous.  I know it may be
>>> easier to just make a room in the basement, but then you have to
>>> soundproof the floors, etc.
>> If your child is something that you frequently clone back into your
>> brain, then sure.
>>
>> It's more like being able to backup and merge yourself [common scifi
>> subject nowadays]. You'll want to kick off versions to experiment on
>> something risky and then bring back the value from its results.
>>
>>> Better to just spring for another artifactId ;)
> Not sure that's necessary?
>
>> As long as they end up in the same release.
>>
>> Sounds painful build-wise. I guess I get to do the multi-pom thing
>> *memories rear in back of head*. Looks like JCI and VFS do this, so
>> I'll figure out how they do things build-wise.
> Commons NET creates 3 binary jars:
> - main
> - ftp + dependencies
> - examples
>
> and does not need a separate module, but there may be advantages to
> having a separate module.
>
The big advantage is that you can release independently from the
"parent"

Lots of releases of [foo-alpha], relatively fewer releases of [foo]
that merge back stable stuff from [foo-alpha]

Phil
>> Hen
>>
>> ---------------------------------------------------------------------
>> 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