James Carman wrote:
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?
+1
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
