Jukka Zitting wrote: > > IMHO, the trunk should contain *exactly* what goes into a release. > I.e. a release should pretty much be just a packaged export of a > tagged version of the trunk. > > If we want to track things that aren't (yet) going to be included in > the next release, then they should be kept outside the trunk. Please keep in mind that Sling is a very modular system consisting mainly of a variety of bundles. Sling has the intent to separately release single modules (bundles). This is one of the number one priorities for Sling - the big bang releases are just for convenience. We might have two to four big bang releases while we will have single bundle releases at any time.
We already have a huge number of bundles but it's most likely that this number will increase over time; the more success we have, the more bundles we get. And it is also often the case that a bundle has been developed by a single developer and contributed. To avoid maintenance problems other projects had with a growing number of modules and usual fluctuation in the community, we should address this issue now and come up with some guidelines which will help us to better maintain the project but also give the users a better picture of what Sling contains. We had/have similar problems within the Cocoon project; we grew up to have over 55 so called blocks (bundles) and only a few of them were really maintained by an active community. So it was hard to tell if and who is able to fix a bug in this module. We tried to compensate this later on by adding a wiki page listening all blocks and their active maintainers. But what of course happened is that this wiki page never really has been maintained, so in the end it's pretty useless for the user. With this structure we give a clean sign what we really support and which parts we would like to support but may be are not able to. We can/ will have release out of the contrib dir as well, but this are single module releases then and driven by community requests. We, Felix and I, also thought about doing something like: /sling/trunk - the maintained stuff /sling/contrib - the contrib stuff But this directory layout creates too much of a friction. People checking out Sling never see the Contrib stuff. We could also do something like /sling/trunk/"core" (I've no good name for this, so I just choose "core") /sling/trunk/contrib But this looks ugly from a directory layout perspective as well. So I think the current proposal is a best efforts. Carsten -- Carsten Ziegeler [email protected]
