On 8/5/10 5:43 PM, David Savage wrote:
On Thu, Aug 5, 2010 at 7:29 PM, Richard S. Hall<[email protected]> wrote:
On 8/5/10 11:47, David Savage wrote:
On Thu, Aug 5, 2010 at 2:19 PM, Richard S. Hall<[email protected]>
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.
-> 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
