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] Phil >> Hen >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
