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