On Oct 2, 2006, at 1:07 PM, Jason Dillon wrote:
The main problem with compromise in this case... (not that I am
unwilling to do so), is that it appears that _any_ compromise
results in the same problem which I am trying to lead us away
from. That problem being a complicated build and release process
due to needing deep insight into the dependencies of each spec (or
in your example, the groups of specs).
No, I wasn't advocating groups of specs. Was more saying "let's just
delete these specs from trunk" or otherwise get rid of them and leave
only the specs that change and do the one version number thing. The
code is tagged, so it's safe. Perhaps the issue is that we don't
need these unchanging modules in trunk in the first place. And just
so you don't think I'm ignoring pom changes, the poms for the modules
I listed are stable to (no deps on anything that's changed).
Thoughts?
-David
--jason
On Oct 2, 2006, at 11:16 AM, David Blevins wrote:
On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
In any case PLEASE think about this and make your opinion known
soon.
If we could at least make a compromise that'd be very great, all
or nothing is not the only way.
Maybe we could just remove these core specs from trunk or
something (we have several tags):
ejb
servlet
jsp
jms
transaction
connector
qname
If all the rest became "one version number" specs released at the
pace of the most changing spec, that'd still be less desirable but
be at least better.
Maybe not the best idea, just trying to find some middle ground.
Thoughts?
-David
