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]
