Graduation vs. release

["Richard S. Hall" <he...@ungoverned.org>]

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.

Re: Graduation vs. release

[Enrique Rodriguez <en...@gmail.com>]

Richard S. Hall wrote:
...
> 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.
...
> Comments on the above and on things that I am forgetting are welcome.

On the incubator list they also pointed out that the copyright years 
were altered on the forked servlet code from Tomcat:

"
It also seems that Felix has forked Tomcat's servlet code - which is okay:

http://svn.apache.org/repos/asf/incubator/felix/trunk/javax.servlet/src/main/java/javax/servlet/GenericServlet.java

However, the copyright years have been altered from the original file
- removing 2004 and adding 2005 - which isn't okay:

http://svn.apache.org/repos/asf/tomcat/servletapi/branches/servlet2.3-jsp1.2-tc4.x/src/share/javax/servlet/GenericServlet.java
"

Enrique

Re: Graduation vs. release

["Richard S. Hall" <he...@ungoverned.org>]

Felix Meschberger wrote:
> First of all, I would thank everyone for the great work which has been
> done here ! It is really a pleasure using Felix.
>
> Second, I would very much welcome a release, of course. IMHO it needs
> not be a 1.0 release, but it might enhance visibility of the product
> in the community.

Yes, I wasn't thinking of a 1.0 release either, I was thinking of 
finishing off the 0.8.0 release that we started a few months back.

Thanks for your support.

-> richard

>
> + 1 to cut a release (nonbinding)
> + 1 to include bundlerepository with the release (nonbinding)
>
> Regards
> Felix
>
>>
>> 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.
>>

Re: Graduation vs. release

[Felix Meschberger <Fe...@day.com>]

Hi,

First of all, I would thank everyone for the great work which has been
done here ! It is really a pleasure using Felix.

Second, I would very much welcome a release, of course. IMHO it needs
not be a 1.0 release, but it might enhance visibility of the product
in the community.

+ 1 to cut a release (nonbinding)
+ 1 to include bundlerepository with the release (nonbinding)

Regards
Felix

>
> 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.
>

Re: Graduation vs. release

[Jeremy Boynes <jb...@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.

Re: Graduation vs. release

["Richard S. Hall" <he...@ungoverned.org>]

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.

Re: Graduation vs. release

["Richard S. Hall" <he...@ungoverned.org>]

Noel J. Bergman wrote:
>> 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
>>     
>
> Actually, it was only somewhat discouraged.  "Could not" is far too strong,
> since many projects do one or two releases before graduating.
>   

Yes, you are right, that is too strong of wording...I guess it just felt 
that way. ;-)

> This came out of the observation that projects often error in their initial
> release preparations, so going through the process, even without actually
> making a release, is a very useful exercise for everyone.
>   

Yes, this was my thought originally.

> Please keep in mind: you do not need to actually release anything.  We do
> not need to vote to release.  We just want to see a release prepared, so
> that we can verify that your processes properly address licensing,
> notification, etc. in what would be the release.

Understood, but we might as well go ahead and make it publicly visible 
in some way, since I think that feedback will also help up learn some 
things.

-> richard

RE: Graduation vs. release

["Noel J. Bergman" <no...@devtech.com>]

> 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

Actually, it was only somewhat discouraged.  "Could not" is far too strong,
since many projects do one or two releases before graduating.

> but now it seems that we must prepare a release as a prerequisite
> for graduation.

This came out of the observation that projects often error in their initial
release preparations, so going through the process, even without actually
making a release, is a very useful exercise for everyone.

> 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.

Please keep in mind: you do not need to actually release anything.  We do
not need to vote to release.  We just want to see a release prepared, so
that we can verify that your processes properly address licensing,
notification, etc. in what would be the release.

	--- Noel