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).
IMO, splitting up into a smaller subset of groups for specs is no
better than having a separate tree for each.
I do not believe that multi-versioned spec maintenance will scale
well... and in some ways I think it has already kinda proven that. 3
small groups for 1.4, 1.5 and other is already on the verge of
becoming more work than it should be due to the overlap and
dependencies.
I will even go as far as saying that for most large project multi-
versioning will not scale. Consider how much work it would be to
keep G in sync if each and every module (config, code, app
deployable, app deployable component, assembly and plugin) were
individual versioned to live up to the code to version purity fallacy.
Well, I can tell you that is a massive nightmare in the works... I've
been there already in fact, a few times, most recently at my last
gig. When I got there I saw developers with little stickys on their
cubes listing versions and compatibility of like 60 different
modules... where it took developers hours to make releases for each
module, which ended up causing more problems if something was missed
or a mistake was made that cascaded down to other dependent modules
which ended up causing the entire thing to be re-released. It took
me almost 5 months to un*uck that mess (of which a lot of time was
spent sending mails kinda like this one)... and in the end I left
them in a state where they could automate *every* build and every
release at the click of a button on a browser. What used to take
hours and caused a bunch of problems due to an overly complicated
process to make a simple code release, could now be done in a few
minutes and was highly reliable, repeatable and simple.
--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
