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: A long time ago...
Date Fri, 06 Aug 2010 13:31:03 GMT


On 8/6/10 6:33, David Savage wrote:
> On Thu, Aug 5, 2010 at 11:54 PM, Richard S. Hall<heavy@ungoverned.org>  wrote:
>>
>> On 8/5/10 5:43 PM, David Savage wrote:
>>> 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.
>> If you think there's a chance to release them independently, I'd just go
>> ahead and create the files now if I were you, since it isn't that much work.
> Ok I'll give it a go, other thought that just occurred - I assume I
> should tag releases in svn - do you usually tag release candidates too
> - probably overkill?

Only the release ends up with a tag.

> Looking at the felix releases tags in svn [1] I guess I should tag all
> the sigil bundles individually too - so that I can do individual
> releases later.

Think of it this way: one release tag for each individually downloadable 
unit. If this time around you are going to only package everything up in 
one tar ball, then you only need one. You can change that in the future.

Of course, there is sort of an assumption that everything being released 
now has the same version number. If you break things out later, it would 
be odd if individual bundles had a lower version number than this first 
lumped together release.

And like Stuart says, the source release is the real important one, but 
typically we provide a convenience binary build for each source release 
we do.

-> richard



> Regards,
>
> Dave
>
> [1] https://svn.apache.org/repos/asf/felix/releases/
>
>> ->  richard
>>
>>> Regards,
>>>
>>> Dave
>>>
>>>> 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

Mime
View raw message