You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by David Savage <da...@paremus.com> on 2010/08/05 12:41:10 UTC
A long time ago...
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.
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
Re: A long time ago...
Posted by David Savage <da...@paremus.com>.
On Thu, Aug 5, 2010 at 7:47 PM, Stuart McCulloch <mc...@gmail.com> wrote:
> On 6 August 2010 00:07, David Savage <da...@paremus.com> wrote:
>
>> On Thu, Aug 5, 2010 at 5:00 PM, Stuart McCulloch <mc...@gmail.com>
>> wrote:
>> > ---> http://felix.apache.org/site/release-management-nexus.html
>>
>> Right I guess I could push it to a mvn repo - but not sure if that'll
>> be any use for eclipse bundles - if people want to test them that is.
>>
>
> for non-maven builds it's probably easiest to make the staged release
> available from your account on people.apache.org under ~/public_html
>
> ( see http://tuscany.apache.org/making-releases.html for an example )
Thanks that looks like a very useful set of notes - I'll dig through
and come up with something...
>
>
>> Does nexus support generation of an update site for a set of
>> features/plugins? If so that'd be great...
>>
>
> nexus-pro has support for p2 update sites, not sure about generating
> them from a set of binaries - of course you could use tycho for that :)
>
> ( http://tycho.sonatype.org )
Yeah that's a possibility :) I'd like to hook in the sigil resolver to
Tycho eventually and have the basic plan of what to do. It's just
never quite yet become the priority.
I currently have a pretty simple groovy script [1] for generating the
old style eclipse update site which works for now with eclipse. Guess
I may need to move to the p2 format update site at some point...
Thinking about it in the medium term possibly I need to do both,
publish the artifacts to maven for maven/tycho builds to consume and
build an update site for eclipse to download. Hmmm ponders...
Regards,
Dave
[1] https://svn.apache.org/repos/asf/felix/trunk/sigil/bldcommon/updatesite.groovy
>
>
>> Regards,
>>
>> Dave
>>
>
> --
> Cheers, Stuart
>
Re: A long time ago...
Posted by Stuart McCulloch <mc...@gmail.com>.
On 6 August 2010 00:07, David Savage <da...@paremus.com> wrote:
> On Thu, Aug 5, 2010 at 5:00 PM, Stuart McCulloch <mc...@gmail.com>
> wrote:
> > ---> http://felix.apache.org/site/release-management-nexus.html
>
> Right I guess I could push it to a mvn repo - but not sure if that'll
> be any use for eclipse bundles - if people want to test them that is.
>
for non-maven builds it's probably easiest to make the staged release
available from your account on people.apache.org under ~/public_html
( see http://tuscany.apache.org/making-releases.html for an example )
> Does nexus support generation of an update site for a set of
> features/plugins? If so that'd be great...
>
nexus-pro has support for p2 update sites, not sure about generating
them from a set of binaries - of course you could use tycho for that :)
( http://tycho.sonatype.org )
> Regards,
>
> Dave
>
--
Cheers, Stuart
Re: A long time ago...
Posted by David Savage <da...@paremus.com>.
On Thu, Aug 5, 2010 at 5:00 PM, Stuart McCulloch <mc...@gmail.com> wrote:
> On 5 August 2010 23:47, David Savage <da...@paremus.com> wrote:
>
>> On Thu, Aug 5, 2010 at 2:19 PM, Richard S. Hall <he...@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?
>>
>> > * 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?
>>
>
> ---> http://felix.apache.org/site/release-management-nexus.html
Right I guess I could push it to a mvn repo - but not sure if that'll
be any use for eclipse bundles - if people want to test them that is.
Does nexus support generation of an update site for a set of
features/plugins? If so that'd be great...
Regards,
Dave
>
>
>> 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
>
Re: A long time ago...
Posted by Stuart McCulloch <mc...@gmail.com>.
On 5 August 2010 23:47, David Savage <da...@paremus.com> wrote:
> On Thu, Aug 5, 2010 at 2:19 PM, Richard S. Hall <he...@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?
>
> > * 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?
>
---> http://felix.apache.org/site/release-management-nexus.html
> 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
Re: A long time ago...
Posted by Stuart McCulloch <mc...@gmail.com>.
On 6 August 2010 18:33, David Savage <da...@paremus.com> wrote:
> On Thu, Aug 5, 2010 at 11:54 PM, Richard S. Hall <he...@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<he...@ungoverned.org>
> >> wrote:
> >>>
> >>> On 8/5/10 11:47, David Savage wrote:
> >>>>
> >>>> On Thu, Aug 5, 2010 at 2:19 PM, Richard S. Hall<he...@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?
>
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
Re: A long time ago...
Posted by David Savage <da...@paremus.com>.
On Fri, Aug 6, 2010 at 2:31 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>
>
> On 8/6/10 6:33, David Savage wrote:
>>
>> On Thu, Aug 5, 2010 at 11:54 PM, Richard S. Hall<he...@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<he...@ungoverned.org>
>>>> wrote:
>>>>>
>>>>> On 8/5/10 11:47, David Savage wrote:
>>>>>>
>>>>>> On Thu, Aug 5, 2010 at 2:19 PM, Richard S. Hall<he...@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.
Right, everything in the sigil bundles is at 0.9.0 at the moment and
when I push the initial release I'll bump it forward to 1.0.0
In effect there are two deliverables from the sigil build at the
moment - though they depend on the various underlying bundles.
There's the eclipse update site - which contains a bunch of bundles
(as you'd imagine) and there's the
org.apache.felix.sigil.ivy.resolver.jar which is a plugin module for
ivy and aggregates all the sigil.common and sigil.ivy packages into
one bundle for convenient install in ant.
To build the ivy plugin, depends on sigil.common and sigil.ivy and to
build the eclipse update site depends on sigil.common and
sigil.eclipse...
So it seems like one way to go would be to tag common and ivy as 1.0
first. Then when the eclipse integration is ready for a 1.0 (retag
common as 1.2 - if it's changed) and tag eclipse as 1.0.
Of course I might also have to do some jiggling of the build scripts
for this to work as I guess we need to be able to build the sub
modules individually? - currently common, ivy and eclipse depend on a
shared bldcommon directory to specify global config - potentially
bldcommon should be tagged as well.
So the final steps to build the release would be to, tag, tag, tag etc
svn co .../releases/sigil.bldcommon-1.0 bldcommon
svn co .../releases/sigil.common-1.0 common
svn co .../releases/sigil.ivy-1.0 ivy
ant -f bldcommon/build.xml clean dist
Or something similar...??
Regards,
Dave
>
> 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
>
Re: A long time ago...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 8/6/10 6:33, David Savage wrote:
> On Thu, Aug 5, 2010 at 11:54 PM, Richard S. Hall<he...@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<he...@ungoverned.org>
>>> wrote:
>>>> On 8/5/10 11:47, David Savage wrote:
>>>>> On Thu, Aug 5, 2010 at 2:19 PM, Richard S. Hall<he...@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
Re: A long time ago...
Posted by David Savage <da...@paremus.com>.
On Thu, Aug 5, 2010 at 11:54 PM, Richard S. Hall <he...@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<he...@ungoverned.org>
>> wrote:
>>>
>>> On 8/5/10 11:47, David Savage wrote:
>>>>
>>>> On Thu, Aug 5, 2010 at 2:19 PM, Richard S. Hall<he...@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?
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
>
Re: A long time ago...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 8/5/10 5:43 PM, David Savage wrote:
> On Thu, Aug 5, 2010 at 7:29 PM, Richard S. Hall<he...@ungoverned.org> wrote:
>> On 8/5/10 11:47, David Savage wrote:
>>> On Thu, Aug 5, 2010 at 2:19 PM, Richard S. Hall<he...@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.
-> 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
Re: A long time ago...
Posted by David Savage <da...@paremus.com>.
On Thu, Aug 5, 2010 at 7:29 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> On 8/5/10 11:47, David Savage wrote:
>>
>> On Thu, Aug 5, 2010 at 2:19 PM, Richard S. Hall<he...@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.
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
>
Re: A long time ago...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 8/5/10 11:47, David Savage wrote:
> On Thu, Aug 5, 2010 at 2:19 PM, Richard S. Hall<he...@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.
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
Re: A long time ago...
Posted by David Savage <da...@paremus.com>.
On Thu, Aug 5, 2010 at 2:19 PM, Richard S. Hall <he...@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?
> * 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
>
Re: A long time ago...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
* Then just follow the release steps in our development
documentation section for Nexus, which discusses signing, etc.
That's pretty much it, I think. You can look at other subprojects for
specific examples or just ask.
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