On Thu, Aug 5, 2010 at 11:54 PM, Richard S. Hall <[email protected]> wrote: > > > 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.
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? 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. 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 >
