Felix community:
It appears that there was some confusion about the requirements for
graduation. In the past we were told that we could not do a release of
Felix while in the incubator, but now it seems that we must prepare a
release as a prerequisite for graduation.
My view is that the framework is ready for release, so this is not
necessarily a huge burden, we just have to tie up some loose ends. I do
not think it is necessary to create official releases for every
subproject, since many of them are in varying degrees of readiness with
respect to their public releases. Furthermore, the whole point of the
modularity of OSGi technology is that it promotes independent
development and release cycles, so the subprojects are intended to
evolve independently, at their own pace.
To make an official release of the framework, I believe we only need to
create official releases for the following subprojects:
* framework - this one goes without saying.
* main - this one goes without saying too.
* shell - we need some way to issue framework commands.
* shell.tui - we need some way to interact with the framework.
* bundlerepository - this one is the most questionable for release,
but it has always been one of the standard bundles, so I would
like to include it...we may have to think about the actual
repository file we ship with, though.
I think all of the above subprojects are ready to go as is with respect
to their functionality. The following is a list of some loose ends that
need to be tied up:
* Fix all headers to meet the requirements defined in
http://www.apache.org/legal/src-headers.html.
* Create an appropriate LICENSE file.
* Create an appropriate NOTICE file.
* Determine how the OSGi interface source and classes must be handled.
* Determine version numbers for subprojects, especially those that
will be released along with the framework.
* If we release bundle repository as part of the framework install,
then determine what we will do for the repository.
We can also debate whether or not this is an actual release or a dry
run, but I don't see much point in that. If we get all of this stuff
done, then it will effectively be a real release, so no dry run is
really necessary. We can still label it as a "release candidate" or
whatever we want, but I would argue for making it publicly available
since we have to figure out how we are going to do that too and we can
possibly get feedback on the release...once we graduate we can just
change its label to "final" or we may actually get some feedback on
issues that we can resolve for the official release after graduation if
we make the release public now.
Comments on the above and on things that I am forgetting are welcome.
-> richard
p.s. I have created JIRA issues for the above and have attached them to
version 0.8.0.
