cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: [Proposal] Document development/maintenance practices
Date Wed, 10 Mar 2004 16:03:15 GMT
Tim Larson <tim@keow.org> writes:

> At my workplace they are worried that pairing their slow 
> upgrade cycle with the fast pace of open source projects 
> could cause maintenance problems for their custom code.  

I find the premise a tad strange; you've got the source, what's to
prevent you from sitting on a single release for ever if that's all you
need?  Skip a release or two if you want, we sat on the 2.0 branch for
well over a year after the 2.1 branch was out.  We finally got to a
point in our own development where we needed features from 2.1 and by
that point it was already up to 2.1.3

> They 
> are concerned that a delayed upgrade may be as painful as 
> switching to another project.  

It took us about 2 days to switch from 2.0.4 to 2.1.3, don't know how
that bench marks with others?  We had to touch about 40 of our classes,
mostly for very minimal stuff.  We had to change our build, we had to
change our xconf. Pretty typical stuff and much in line with upgrading
any other major piece of software be it open source or proprietary (eg.
migrating from one version of Websphere to another has been harder when
we used to use Websphere).

> I propose we create a document 
> detailing the practices and policies we follow to minimize 
> this risk to users of Cocoon.
> 
> To start the discussion, here is a seed list of practices 
> that I have noticed we try to be known for following:
> 
>   [Disclaimer: We are under no contract and offer no warranty
>   concerning these practices (see our license for details.)]
> 
>   Continuing to support older releases
>   Maintaining a change log to help with upgrades
>   Strongly avoiding breaking interfaces
>   Conducting open, public discussion of design and development
>   Querying userbase to determine impact of potential changes
>   Responding to the userbase, even reverting changes when necessary
>   Voting on major additions, changes, deprecations, and removals
>   Deprecating interfaces instead of immediately dropping support
>   Only allowing code that has a community to support it
> 
> What do others think about developing a document like this
> to document our guidelines and improve our marketability?
> Do we already have a document like this somewhere?

I would expect that people that are using Open Source already know why
they are doing so; if not they need to be indoctrinated :-)  By that I
mean read the Cathedral and the Bazaar, etc...  After all, isn't this
kind of thing why people buy into Open Source in the first place?  RT:
maybe, the documentation you propose should be more of an Apache level
thing that a project level thing?

One thing I would point out that we now do is we maintain our own source
controlled copy of Cocoon.  When a new Cocoon release is made we
baseline it.  We hardly ever touch the code, but even such things as
adding a new module from scratchpad is then tracked on our source
control system so we know exactly what pieces of Cocoon we are using.
If we do touch the code, we can easily do a diff to see what our changes
are vs. the core Cocoon. If we happen to really need a CVS version of
Cocoon we can do a diff and see exactly what changes are taking place
vs. the version of code we are currently touching (though the one time I
did this it was so much information it would have taken 2 days or so to
really understand the impact).

We started this process when we moved to Cocoon 2.1.3 and as a result it
took about 4 hours to move to 2.1.4 release (if we had done this for the
2.0.4 release I think it would have cut our migration time in half to go
to 2.1.3). 

 


Mime
View raw message