Hi Let my post my view of this problem from the outside and as a member of the Felix and Sling projects.
In Felix we don't have a "global" release. We only have individual module releases, such as the framework, the webconsole, declarative services, configuration admin, iPOJO, etc. This works very well. In fact given the independent nature of these module, this is probably the only viable way to have regular releases. In Sling, which resembles a traditional Apache project more that Felix, we also do single-module releases. Of course we understand the need of people to be able to grab a prepackaged version and thus we try to regularly release prepackaged versions. In contrast to modules, we have a single position counter for this prepackaged releases. The first rlease was Sling 5 and currently we are working towards a Sling 6 release. Point is really, that we are living in a modular world where not everything can be coordinated to the point of having everything ready for release at the same time. Some modules evolve more than other modules do. And there is no point in creating a release of a module which has not been modified since the last release. So we leverage OSGi since Sling is running in an OSGi framework: We assume the package exporters act responsibly and do not introduce incompatible changes (yes, we (try to) adhere to OSGi's recent semantic versioning white paper). Thus we try to set the maven dependencies in our modules to the lowest version possible; put the other way: we don't upgrade dependencies just because there is a new version available. Regarding initial versions: Since modules evolve independently, there is no "prevailing" version. Thus my stance is to start with 1.0 for the first release. As for downloading: Of course we provide the latest "full Sling release" through the down load page. But since we also do module releases, we just list the latest release of each module on the same download page. In addition we maintain an OSGi Bundle Repository from where bundles can directly be installed (e.g. with the Apache Felix Web Console). Apache Felix does the same, btw. ([3], [4]) Some thoughts on versioning in Sling is also documented in [1] and [2]. Hope this helps. Regards Felix [1] http://sling.apache.org/site/dependency-management.html [2] http://sling.apache.org/site/version-policy.html [3] http://sling.apache.org/site/downloads.cgi [4] http://felix.apache.org/site/downloads.cgi On 20.08.2010 22:02, Joe Bohn wrote: > > We're in the process of releasing our second set of modules. This sheds > new light on the module version and release process discussions we had > earlier. It also raises some questions about how we ideally want to > handle certain scenarios now that we are forced to deal with more than > one release. > > 1) Should the first release of a new module use the prevailing version > at the time or do we intend to always start with the logical "1" of a > first release? For quiesce we used the prevailing version - > 0.2-incubating. > > 2) How will we make multiple component versions available in the future > for download? If we always release all modules (as we did in our 0.1 > and 0.2 releases) then it's simple - we can create a download page for > each release and we can create documentation per release. However, if > we start to release the modules individually things get a bit more > complicated. One possibility is to move from one common download page > to a download page per module. > > 3) Are there other benefits in keeping the module versions consistent > and concurrently releasing all modules rather than individual modules > that we haven't really considered? I'm thinking about things like > documentation, test validation, and samples. > > Thinking more about #3 - It seems it might be very difficult to maintain > our documentation and samples once the module versions begin to diverge. > Changes to one module might force us to want to release or update some > other module, ... such as the case with (and perhaps only with) samples. > In fact, samples might be impacted by the release of each module if we > want to try to keep them as current as possible. This might result in a > proliferation of sample releases. Moreover, the combination of > modules/versions we use in our sample releases might not demonstrate or > validate a common set of modules/versions that a user might choose. Yes, > all valid versions based upon dependencies *should* work fine together > ... but that assumes nobody makes mistakes. There is a certain comfort > (from a user perspective) in knowing that a particular set of modules > has been tested together in some fashion which can at least be partially > demonstrated in our samples. > > I understand why we started down the path of individual components and I > definitely agree that it has value ... I'm just rethinking the decision > now that we are doing our second release and have to deal with multiple > versions for the first time. The second release begins to set the > precedent for how we deal with some of these things. The fact that we > basically released everything again with a consistent version makes me > wonder if that should be our standard process instead of individual > component versions. >
