All, Ok, folks, so where are we on this? There has been some desire to reorganize things a bit. There are at least 3 options that I have heard:
1. Leave everything the way it is. 2. Set everything up the way I suggested (the projects can still have a common parent that's a sibling of theirs like we do in commons) 3. Use a hybrid approach, creating some "umbrella" project that is updated/released with the Wicket releases and follows the Wicket release numbering/schedule. Is this what folks have proposed as solutions? If so, should we start a [VOTE] just to see where we are on these three solutions? James p.s. Sorry to be such a stickler, but I'm one of those folks who has to have order. I can't work until I clean my desk up first! :) The first step is identifying the problem and I'll get right on that when I'm done cleaning up my desk! On Wed, May 21, 2008 at 3:31 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > flattery will get you everywhere > > -igor > > On Wed, May 21, 2008 at 12:29 PM, James Carman > <[EMAIL PROTECTED]> wrote: >> With the quick release cycles that Wicket goes through, that just >> seems weird to me. They should pick a version and go with it. The >> Wicket team is very good about keeping things fresh. I have been very >> surprised at how many releases have gone out in my brief experience >> with Wicket. >> >> On Wed, May 21, 2008 at 3:27 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >>> well, the problem is that most trunks depend on wicket snapshots >>> >>> -igor >>> >>> On Wed, May 21, 2008 at 12:05 PM, James Carman >>> <[EMAIL PROTECTED]> wrote: >>>> On Wed, May 21, 2008 at 3:00 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >>>>> well, thats what we get for having virtually no entry barrier. for me >>>>> branching the entire repo with every major release of wicket is much >>>>> easier because i can do it with one command. if each project has their >>>>> own tree i am not going to do it. that means when there is an api >>>>> change in wicket all projects will have to be upgraded or they wont >>>>> compile. >>>> >>>> They will compile because they're dependencies are not being modified >>>> by the Wicket release. Existing projects (if they don't follow the >>>> release cycle of Wicket) can specify whatever version of Wicket they >>>> *do* compile/run against. As long as nobody changes that (and nobody >>>> checks in messed up code), the project should compile and run just >>>> fine against the specified release(s) (remember, you can specify >>>> version ranges in Maven, too). >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
