cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: [Proposal] Document development/maintenance practices
Date Tue, 09 Mar 2004 20:02:26 GMT

First off: this is a very good idea.

For what it's worth, I'd like to offer some ideas on this. If you go ahead
and write this document, why not take it a bit further and make things more

> >   Continuing to support older releases

State how long support for older releases will be available. It sounds
reasonable if all 2.1.X releases are supported, but only the last of 2.0.X
and of 1.X. This doesn't of course prevent anyone from giving support on
other releases. ;-)

> >   Maintaining a change log to help with upgrades

As mentioned before: add scripts/XSL/instructions to help with the change.

> >   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

e.g. state how long deprecated code will be around before it is actually
removed (e.g. X releases later). I suppose this will also avoid several
"vote" threads. 

> >   Only allowing code that has a community to support it

If new things are added (e.g. workflow), they always start as a scratchpad
block with "scratchpad" actually in the package name. Once they reach
maturity to earn their own block they are moved to a regular block outside
the scratchpad. Now I see lots of blocks marked as "scratchpad" in the
build, but hardly any of them are actually in src/blocks/scratchpad.

Is it possible to move deprecated code to a src/**/deprecated without
changing the package names? In this case it is also more clearly which code
is deprecated.

Yes, I know: all this requires more work, but I think it makes the
"contract" more clearly.

Bye, Helma

View raw message