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: Felix release approach
Date Fri, 03 Nov 2006 17:40:53 GMT
I remember yet another thing I wanted to mention...the current example 
release is a source+binary release. I also anticipate that we will do 
just a binary release archive, which would be pretty much the same as 
the source release, but simply remove the trunk/ directory.

-> richard

Richard S. Hall wrote:
> One other comment I should add, I am not anticipating that we release 
> every bundle in the first initial release. I think the initial release 
> will only include shell, shell.tui, bundlerepository just to get 
> things going. Of course, we can debate this as part of this process, 
> but the main goal is to just get something out there ASAP.
> -> richard
> Richard S. Hall wrote:
>> Two weeks ago I started to get frustrated about not making any 
>> progress on a Felix release. The main blocker for me is that I don't 
>> really know anything about the installer package we have set up to do 
>> "fancy" release packages with services, nor do I have enough time to 
>> try to learn about it right now. In the end, I got to thinking that 
>> we don't actually need to have a "fancy" release for our first 
>> release and could instead just work on a simple "zip-file" release 
>> that people just download and unzip.
>> I worked with Karl Pauls over the last few days to create a simple 
>> archive release that could meet the Apache release requirements. I 
>> put an example of such a zip-file release for Felix 0.8.0 at:
>> http://people.apache.org/~rickhall/felix-src-0.8.0-incubator-SNAPSHOT.tar.gz 
>> Karl has examined this example release with the RAT tool, so we think 
>> we have most of the issues covered. The purpose of this message is to 
>> get feedback on two issues:
>>   1. Whether or not everyone agrees that we should just go ahead with a
>>      simple zip-file release. (I will call a formal vote on this in a
>>      separate message so we will know one way or the other how to 
>> proceed.)
>>   2. Assuming that we do agree on (1), get feedback on the above
>>      example release in case there are any issues that we still need to
>>      address.
>> If we can get consensus on this approach, then we can vote on the 
>> release itself (assuming that we can fix any issues that may exist), 
>> vote on a release manager to take responsibility for the release, and 
>> then take the release to the incubator PMC.
>> -> richard

View raw message