felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Savage <david.sav...@paremus.com>
Subject Re: A long time ago...
Date Thu, 05 Aug 2010 21:43:54 GMT
On Thu, Aug 5, 2010 at 7:29 PM, Richard S. Hall <heavy@ungoverned.org> wrote:
>  On 8/5/10 11:47, David Savage wrote:
>> On Thu, Aug 5, 2010 at 2:19 PM, Richard S. Hall<heavy@ungoverned.org>
>>  wrote:
>>>  On 8/5/10 6:41, David Savage wrote:
>>>> Hi there,
>>>> I realise it's been quite a while since we donated Sigil to Apache and
>>>> I'm yet to push out a release. That said I've been making quite a bit
>>>> of progress with it in the background [1] and I'd like to start
>>>> figuring out what tasks I need to do to get these bundles released.
>>>> Signing jars seems to be one task that needs doing, also setting up
>>>> appropriate LICENSE files, but I'm sure there's other stuff. Having
>>>> not pushed out an apache release before I'd appreciate any pointers to
>>>> get me going.
>>> The main things are:
>>>   * Make sure that all files of any significance have the Apache
>>>     header in them.
>>>   * In the root of all bundle projects, include LICENSE, NOTICE, and
>>>     DEPENDENCIES files.
>>>         o LICENSE is the standard license text, NOTICE contains any
>>>           required notices from included software, and DEPENDENCIES is
>>>           like an expanded NOTICE where we acknowledge all top-level
>>>           dependencies.
>>>         o These files should ultimately also end up in the META-INF/
>>>           directory of the resulting bundle JAR file.
>> Ok makes sense - just to be clarify I've setup the sigil projects
>> under the following structure:
>> $sigil/common - has dependencies on bnd and osgi.framework and osgi.cmpn
>> $sigil/ivy - has dependency on ivy, common + common deps
>> $sigil/eclipse + has dependency on eclipse, common + common deps
>> Guess it make sense to have different NOTICE/DEPS for each sub module?
> If you are planning to only have a single combined release of everything
> (i.e., every release is monolithic), then you can just have one set for all
> of them. However, I'd imagine you'd keep everything modular and allow for
> different release schedules for the various modules, if so then you need one
> set per module.

Right I am debating doing a common/ivy release first as that stuff is
pretty rock solid, the eclipse subsystem is very usable but if it was
a perfect world I'd finish off the runtime/debug support before
pushing that to 1.0

There are sub bundles within those top level subsystems but in general
I think it makes sense initially to release them as a unit, possibly
subsequent bug fixes can be done individually...

So yep looks like I need files per subsystem (at least) at the moment.



> So, I guess you need to answer that question first.
> -> richard
>>>   * Then just follow the release steps in our development
>>>     documentation section for Nexus, which discusses signing, etc.
>> Thx I'll take a read through.
>>> That's pretty much it, I think. You can look at other subprojects for
>>> specific examples or just ask.
>> Great, will do.
>> In terms of staging release artifacts should I push these to my
>> people.apache.org/dsavage dir - or is there a folder I can access for
>> felix?
>> Regards,
>> Dave
>>> In the end, you don't have to worry too much, because it's an iterative
>>> process when you call the vote...we'll review the release then, which may
>>> cause you to have to re-do it.
>>> ->  richard
>>>> Regards,
>>>> Dave
>>>> [1]
>>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310100&fixfor=12314109&sorter/field=issuekey&sorter/order=DESC&sorter/field=status&sorter/order=ASC

View raw message