felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Graduation vs. release
Date Mon, 18 Sep 2006 06:42:09 GMT
I should also point out that there are other JIRA issues related to 
release that were entered last time when we started pushing for a 
release, so those items are also included on the list...see the issues 
attached to the 0.8.0 release in JIRA...

-> richard

Richard S. Hall wrote:
> 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.

Mime
View raw message