Can we think carefully about complexity for a second and agree that
the two models under discussion are
trunk/<individual specs at same SNAPSHOT version>
branches/<version>/<all the individual specs at that SNAPSHOT version>
tags/<version>/<all the individual specs at that non-SNAPSHOT version>
and
<each spec>/[trunk, branches/<version>, tags/<version>]
(in the 2nd choice each spec must be built and released individually
by itself, there is no "build all the specs" pom)
and that any other choices are going to make releasing anything
correctly 120% impossible? We already have a system that doesn't
work, thinking up more and more complicated choices is not going to
result in ever releasing anything correctly.
I'll repeat that philosophically I prefer the second solution but I
don't think we have the attention span as a project to make it work
so I'm voting for the first choice. I know if I was in charge of
releasing the specs I would mess up the second choice for sure but I
might be able to make the first choice work. If only half the specs
are in trunk I wouldn't even try to build the specs myself locally.
thanks
david jencks
On Oct 3, 2006, at 10:15 AM, David Blevins wrote:
On Oct 2, 2006, at 1:35 PM, David Blevins wrote:
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?
Thoughts?
Yank these from trunk as they haven't changed in 2+ years?
ejb
servlet
jms
transaction
connector
qname
-David
-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
