On Thu, Apr 7, 2011 at 1:57 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 4/7/11 1:14 PM, sebb wrote: >> On 7 April 2011 21:08, Henri Yandell <flame...@gmail.com> wrote: >>> On Thu, Apr 7, 2011 at 10:48 AM, Phil Steitz <phil.ste...@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]
Very theoretical advantage - it's plausible that we would have a new beta class of some kind to release and no bugfixes; but very unlikely. The two artifacts [if such it must be] are developed in parallel and I expect the 'parent' to release more often than the contrib package. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
