On 6 August 2010 18:33, David Savage <[email protected]> wrote:
> 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? > you should tag the code in svn and then checkout that tag and use it to stage the release, then you know that you're not picking up some code/change that hasn't been checked in > 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. > if they'll be released independently then that makes sense - remember the source is the main 'deliverable' for Apache projects, the binaries, etc. are just a convenience :) [ http://www.apache.org/dev/release.html#what ] 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 > > > -- Cheers, Stuart
