Some thoughts from different perspectives. Sorry for the length, I guess
I'm feeling voluminous tonight :).
Thoughts on Building:
Splitting the releases for the client and server components should be
easy. The server does depend on some features in the client library, but
since we're bundling the client-lib jar it shouldn't be too hard to keep
track of. Splitting client parts up might be harder, since there's the
clientlib, command line client, jca connector and ant tasks.
Splitting the testsuite would require some refactoring of the build
scripts, but from a cursory inspection it doesn't look too major. Does
it make sense to split the testsuite out, though? I haven't played with
it much. Are the the tests all functional or are there any regression
tests that all server versions should pass? I kind of got the impression
it was supposed to be a generic WebDAV testsuite.
I haven't really looked at the build processes for WCK or Projector.
Thoughts on Source Management:
This will probably be a bigger challenge than working out the builds.
Splitting the releases mean splitting up the code. If we don't, we're
going to end up with CVS tags that contain a lot of redundant code
(client tags that contain server code, for instance). I think it might
make sense to migrate to Subversion and then do some restructuring. I
think the migration should come first since it's relatively easy to move
stuff around in Subversion.
Here's a sample structure to get some discussion going:
client/
ant/
clientlib/
commandline/
jca/
projector/
proposals/
server/
kernel/
stores/
file/
jndi/
mem/
rdbms/
txfile/
webdav/
testsuite/
website/
Every folder (except maybe website) should contain HEAD/, branches/ and
releases/ folders, since Subversion treats tags just like normal
folders.
For inter-component dependencies I'm thinking the build scripts could
reference the specific version they depend on (since everything is a
folder in Subversion), and we could maybe even get fancy and
download/build straight from the repository if the user hasn't checked
that version out.
Thoughts in General:
I'd like to split stores into separate components. They don't depend on
each other, and I think it would make it easier to incorporate new
implementations.
I think we should continue with bundled releases (a Tomcat bundle and
complete .war bundle at least) on a quarterly bases, or when there's a
major fix/enhancement.
For me, splitting the release has two advantages:
1) Better componentization. This should make the release cycle more
responsive to bug reports, and hopefully insulate the different pieces
from each other (making things easier to maintain).
2) It raises the visibility of the different components. This might help
grow the community.
Since all this will probably take awhile, here my suggested
sequence/timeline.
1) Migrate to Subversion. We're supposed to be doing this anyway, and it
makes the rest of it easier.
2) Restructure the repository.
3) Release 2.2 alpha, either as a single release or in one or two
components (client and server, maybe).
4) Finish up the 2.1 release. We're close, so hopefully the bugs will be
worked out by this time.
5) Profit... or something like that ;).
-James
On Wed, 2004-12-08 at 01:03 +0100, Oliver Zeigermann wrote:
> My initial idea was the same. But as I gathered some experience with
> WCK which works with both 2.1 and (upcoming 2.2) I am no longer for
> separate releases. Of course Daniel's arguments are valid, but I think
> they are outdone by the drawbacks. Maintaining compatibility to more
> than a release really is hard and unpleasant work.
>
> Oliver
>
>
> On Tue, 7 Dec 2004 21:22:30 +0100, Daniel Florey <[EMAIL PROTECTED]> wrote:
> > The biggest argument splitting Slide into smaller pieces would be to avoid
> > releasing part that didn't change at all with different version numbers.
> > Why releasing webdavclient in release 2.2 in there is no difference between
> > 2.1 and 2.2 (as an example)?
> > So I'd like to see independent releases for:
> > 1. Slide server+stores
> > 2. Webdavclient library
> > 3. Commandline client
> > 4. WCK
> > 5. Projector
> > 6. Testsuite
> > I know that this would be a lot of initial work, but it might be easier
> > later on to make individual releases as we don't have to take care of all
> > subcomponents. And as subcomponents don't have to wait for each other
> > releases with new features can be released earlier.
> > But as I don't have much time at all to work on it, I do not vote for it ;-)
> >
> > Cheers,
> > Daniel
> >
> > > -----UrsprÃngliche Nachricht-----
> > > Von: [EMAIL PROTECTED]
> > > [mailto:slide-dev-return-14961-apmail-
> > > [EMAIL PROTECTED] Im Auftrag von Oliver Zeigermann
> > > Gesendet: Dienstag, 7. Dezember 2004 18:52
> > > An: Slide Developers Mailing List
> > > Betreff: Re: [POLL] 2.2 release time frame
> > >
> > > On Tue, 07 Dec 2004 09:40:09 -0800, James Mason <[EMAIL PROTECTED]>
> > > wrote:
> > > > I'd be fine with a release, I think. I'd really prefer to release 2.1
> > > > before 2.2, though ;).
> > >
> > > Hihi
> > >
> > > > Should we pursue splitting the releases for 2.2, or keep going the way
> > > > we have been with a single large release?
> > >
> > > Good question. The only candidats would be
> > >
> > > a) the testsuite,
> > > b) projector, and
> > > c) WCK
> > >
> > > a) evolves with Slide and the 2.1 test suite works with the 2.1
> > > release only and the CVS head test suite works with the cvs head only.
> > > So, spinning this off would make little sense IMHO
> > > b) No idea, Daniel?
> > > c) WCK more and more relies on 2.2, but still works with 2.1. It would
> > > make sense to release it all by itself, but I have already learned the
> > > tough way how hard it is to maintain it for even two versions of Slide
> > > (2.1 and CVS head).
> > >
> > > In short I would vote for doing one large release. Of course this is
> > > more work for you, James. If this is too much for you, maybe we can
> > > find another solution...
> > >
> > > Oliver
> > >
> > >
> > > > -James
> > > >
> > > >
> > > >
> > > > On Tue, 2004-12-07 at 18:24 +0100, Oliver Zeigermann wrote:
> > > > > Folks,
> > > > >
> > > > > I am a bit concerned about the duration of our release cycles. E.g.
> > > > > some contributions in 2.1 are much older than half a year before they
> > > > > are even released as stable.
> > > > >
> > > > > Apache rule is to release early and often.
> > > > >
> > > > > My proposal is to speed up the cycle for 2.2 and subsequent releases
> > > > > and put less new stuff into each of them. My impression is that 2.2
> > > > > almost has got enough new features to justify a new release.
> > > > >
> > > > > What do you think? What do you want to add and when? What is in your
> > > > > pipeline for 2.2? Mine is empty...
> > > > >
> > > > > Oliver
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
