t;>> > there's an undergoing debate in the XML Graphics project about doing
>>> > a release that has a dependency on a snapshot version of another
>>> > (Apache, for that matter) project.
>>> >
>>>
>>> The fact that it i
L Graphics project about doing
>> > a release that has a dependency on a snapshot version of another
>> > (Apache, for that matter) project.
>> >
>>
>> The fact that it is an Apache project is *key* for my commentary below.
>> Don't take my words f
Am 26.07.2014 15:53, schrieb Andreas Lehmkuehler:
Am 25.07.2014 16:26, schrieb Greg Stein:
I believe you have two options: fork their code into your project, and do
some appropriate subpackage renaming to clarify it is distinct. Or,
ideally, you join *their* community and help them cut a releas
Am 25.07.2014 16:26, schrieb Greg Stein:
I believe you have two options: fork their code into your project, and do
some appropriate subpackage renaming to clarify it is distinct. Or,
ideally, you join *their* community and help them cut a release, and then
base your code on that.
Just to clarify
P
>
>
> >
> > I know there's a policy at Apache to not release a project that has
> > non-released dependencies. The problem is, I don't know how I know
> > that... I cannot seem to be able to find any official documentation that
> > explicitly states i
We followed option # 1 in Apache Geronimo. We grabbed the source for the
dependency projects and built it out of the branch and eventual tag. We hard
too many dependencies to wait for all projects to sync up.
Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x0F143BC1
"Aut Inveniam Vi
> (Apache, for that matter) project.
>
The fact that it is an Apache project is *key* for my commentary below.
Don't take my words for external projects, please :-P
>
> I know there's a policy at Apache to not release a project that has
> non-released dependencies. The pr
