Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <450E34DC.9030205@ungoverned.org>
References: <450E34DC.9030205@ungoverned.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <FEC22DB2-59DB-46EB-AA30-BB3449E76219@apache.org>
Content-Transfer-Encoding: 7bit
From: Jeremy Boynes <jboynes@apache.org>
Subject: Re: Graduation vs. release
Date: Mon, 18 Sep 2006 06:35:38 -0700
To: felix-dev@incubator.apache.org

What is the status of the maven plugin? Would it be possible to  
include that in a release (or potentially do it separately)?
Thanks
--
Jeremy

On Sep 17, 2006, at 10:55 PM, 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.