geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: One version for specs
Date Mon, 02 Oct 2006 20:07:41 GMT
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
>
>


Mime
View raw message