Re: Non-released Dependencies

[Greg Stein <gs...@gmail.com>]

[adding dev@community, as I believe this should go there...]

On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert <vh...@gmail.com>
wrote:
>...

> Hi,
>
> 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 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 problem is, I don't know how I know
> that... I cannot seem to be able to find any official documentation that
> explicitly states it.
>

That's why you can't find it... I don't recall any such "policy" (over the
past 15+ years I've been around) ... it just isn't a good idea. That's all.


>
> The following link: http://www.apache.org/dev/release.html#what is
> apparently not convincing enough. I'm answered that this concerns our
> own project but that it's fine to do an official release containing
> a snapshot binary.
>

Well. You need to produce a full set of sources. No binaries. Those sources
might be by-reference, but you definitely can't release a binary within
your source distribution.

Even if that other Apache project had a release you're happy with, there
would be a source release available for it.


>
> Saying that every binary artefact has to be backed by source code and
> that, in the case of a snapshot, we have to point to some Subversion
> revision number, is apparently not convincing enough either. Despite the
> obvious dependency nightmare that that would cause to users (and, in
> particular, Maven users and Linux distributions).
>

Pause. This is not negotiable. You *must* have a source release. If you do
that through a signed tarball, or through a git tag, or a Subversion
revision number ... all of these identify a *specific* set of source code.
That satisfies the need.

You raise some concerns about nightmares... sure. Telling users "you must
get r123 of /some/path, for $LIBRARY" is not exactly friendly. BUT: it
satisfies all release requirements. It will specify the exact dependency.
Good to go.



>
> Does anybody have any official reference to point at, that I may have
> missed? More convincing arguments, legal reasons (should I forward to
> legal-discuss@)?


Much of this kind of stuff is "institutional knowledge" because having to
write down "rules" and "procedures" just sucks. It is such a rare event,
that it is best to leave it for the particular situation.

There are no legal ramifications, if you're talking about a sibling Apache
project.

Now... you *should not* do any sort of release of a sibling. That will
screw over that community. (version skew, unsupported bits, issue tracking,
blah blah)

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.

Cheers,
-g

Re: Non-released Dependencies

[Andreas Lehmkuehler <an...@lehmi.de>]

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 release, and then
>> base your code on that.
> Just to clarify. We are talking about FontBox which is part of the PDFBox
> project. We don't have any difficulties to release a new version. We are working
> on a new major release containing a lot of new stuff and refactorings. Some of
> them are within FontBox but most are within the core component itself. We are
> planning to cut a release in the late summer but we can't guarantee that as
> there are still a lot of things to do. Any help is welcome, but most of the
> stuff isn't about FontBox anymore but the PDF spec and java rendering stuff.
>
> Saying that, I'm afraid the FOP guys have to fork FontBox if they are in a hurry.
There is maybe another alternative. Maybe it's possible to backport those needed 
features from the 2.0-SNAPSHOT to the 1.8-branch? But I guess that's something 
we should discuss on dev@pdfbox.

>> Cheers,
>> -g
>
> BR
> Andreas Lehmkühler, PDFBox Chair

BR
Andreas Lehmkühler

---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: Non-released Dependencies

[Andreas Lehmkuehler <an...@lehmi.de>]

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 release, and then
>> base your code on that.
> Just to clarify. We are talking about FontBox which is part of the PDFBox
> project. We don't have any difficulties to release a new version. We are working
> on a new major release containing a lot of new stuff and refactorings. Some of
> them are within FontBox but most are within the core component itself. We are
> planning to cut a release in the late summer but we can't guarantee that as
> there are still a lot of things to do. Any help is welcome, but most of the
> stuff isn't about FontBox anymore but the PDF spec and java rendering stuff.
>
> Saying that, I'm afraid the FOP guys have to fork FontBox if they are in a hurry.
There is maybe another alternative. Maybe it's possible to backport those needed 
features from the 2.0-SNAPSHOT to the 1.8-branch? But I guess that's something 
we should discuss on dev@pdfbox.

>> Cheers,
>> -g
>
> BR
> Andreas Lehmkühler, PDFBox Chair

BR
Andreas Lehmkühler

Re: Non-released Dependencies

[Andreas Lehmkuehler <an...@lehmi.de>]

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. We are talking about FontBox which is part of the PDFBox 
project. We don't have any difficulties to release a new version. We are working 
on a new major release containing a lot of new stuff and refactorings. Some of 
them are within FontBox but most are within the core component itself. We are 
planning to cut a release in the late summer but we can't guarantee that as 
there are still a lot of things to do. Any help is welcome, but most of the 
stuff isn't about FontBox anymore but the PDF spec and java rendering stuff.

Saying that, I'm afraid the FOP guys have to fork FontBox if they are in a hurry.

> Cheers,
> -g

BR
Andreas Lehmkühler, PDFBox Chair

Re: Non-released Dependencies

[sebb <se...@gmail.com>]

On 28 July 2014 10:20, Greg Stein <gs...@gmail.com> wrote:
> Agreed that #2 is best.
>
> (and I'll also note I was a bit slack with some commentary; releases need
> to be signed,

Also source releases must be published via the ASF mirror system.

> so a path/revision or git-tag is not necessarily a true

s/necessarily//

> release; just trying to get across that you need a *specific* set of source
> for a dependency)
>
> Seems that Andreas is going to explore some options at dev@pdfbox.
>
> Cheers,
> -g
>
>
>
> On Fri, Jul 25, 2014 at 9:34 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> I think the key bit here is that releases of Apache projects must have an
>> associated source release and have been voted on by the PMC making the
>> release.
>>
>> If the project you depend on is an independent project, you need to
>> remember that their -SNAPSHOT build is *not* a release. Therefore you need
>> it to become a release to include it.
>>
>> You therefore have three choices:
>>
>> 1. Fork the code into your project and do a big-bang release... a rude
>> option but once it's in your project your PMC can vote to release it.
>>
>> 2. Join the dependent project and help them get to a release
>>
>> 3. Find somebody outside the ASF (or at a minimum not wearing an ASF hat)
>> and get them to fork the code you want and release that. Then you can
>> depend on the non-ASF fork of the ASF project... again a rude option, but
>> perhaps less so than #1
>>
>> I vote you go for #2. It plays best with community which is what we are
>> here to foster
>>
>>
>> On 25 July 2014 15:26, Greg Stein <gs...@gmail.com> wrote:
>>
>>> [adding dev@community, as I believe this should go there...]
>>>
>>> On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert <vh...@gmail.com>
>>> wrote:
>>> >...
>>>
>>> > Hi,
>>> >
>>> > 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 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 problem is, I don't know how I know
>>> > that... I cannot seem to be able to find any official documentation that
>>> > explicitly states it.
>>> >
>>>
>>> That's why you can't find it... I don't recall any such "policy" (over the
>>> past 15+ years I've been around) ... it just isn't a good idea. That's
>>> all.
>>>
>>>
>>> >
>>> > The following link: http://www.apache.org/dev/release.html#what is
>>> > apparently not convincing enough. I'm answered that this concerns our
>>> > own project but that it's fine to do an official release containing
>>> > a snapshot binary.
>>> >
>>>
>>> Well. You need to produce a full set of sources. No binaries. Those
>>> sources
>>> might be by-reference, but you definitely can't release a binary within
>>> your source distribution.
>>>
>>> Even if that other Apache project had a release you're happy with, there
>>> would be a source release available for it.
>>>
>>>
>>> >
>>> > Saying that every binary artefact has to be backed by source code and
>>> > that, in the case of a snapshot, we have to point to some Subversion
>>> > revision number, is apparently not convincing enough either. Despite the
>>> > obvious dependency nightmare that that would cause to users (and, in
>>> > particular, Maven users and Linux distributions).
>>> >
>>>
>>> Pause. This is not negotiable. You *must* have a source release. If you do
>>> that through a signed tarball, or through a git tag, or a Subversion
>>> revision number ... all of these identify a *specific* set of source code.
>>> That satisfies the need.
>>>
>>> You raise some concerns about nightmares... sure. Telling users "you must
>>> get r123 of /some/path, for $LIBRARY" is not exactly friendly. BUT: it
>>> satisfies all release requirements. It will specify the exact dependency.
>>> Good to go.
>>>
>>>
>>>
>>> >
>>> > Does anybody have any official reference to point at, that I may have
>>> > missed? More convincing arguments, legal reasons (should I forward to
>>> > legal-discuss@)?
>>>
>>>
>>> Much of this kind of stuff is "institutional knowledge" because having to
>>> write down "rules" and "procedures" just sucks. It is such a rare event,
>>> that it is best to leave it for the particular situation.
>>>
>>> There are no legal ramifications, if you're talking about a sibling Apache
>>> project.
>>>
>>> Now... you *should not* do any sort of release of a sibling. That will
>>> screw over that community. (version skew, unsupported bits, issue
>>> tracking,
>>> blah blah)
>>>
>>> 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.
>>>
>>> Cheers,
>>> -g
>>>
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: Non-released Dependencies

[sebb <se...@gmail.com>]

On 28 July 2014 10:20, Greg Stein <gs...@gmail.com> wrote:
> Agreed that #2 is best.
>
> (and I'll also note I was a bit slack with some commentary; releases need
> to be signed,

Also source releases must be published via the ASF mirror system.

> so a path/revision or git-tag is not necessarily a true

s/necessarily//

> release; just trying to get across that you need a *specific* set of source
> for a dependency)
>
> Seems that Andreas is going to explore some options at dev@pdfbox.
>
> Cheers,
> -g
>
>
>
> On Fri, Jul 25, 2014 at 9:34 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> I think the key bit here is that releases of Apache projects must have an
>> associated source release and have been voted on by the PMC making the
>> release.
>>
>> If the project you depend on is an independent project, you need to
>> remember that their -SNAPSHOT build is *not* a release. Therefore you need
>> it to become a release to include it.
>>
>> You therefore have three choices:
>>
>> 1. Fork the code into your project and do a big-bang release... a rude
>> option but once it's in your project your PMC can vote to release it.
>>
>> 2. Join the dependent project and help them get to a release
>>
>> 3. Find somebody outside the ASF (or at a minimum not wearing an ASF hat)
>> and get them to fork the code you want and release that. Then you can
>> depend on the non-ASF fork of the ASF project... again a rude option, but
>> perhaps less so than #1
>>
>> I vote you go for #2. It plays best with community which is what we are
>> here to foster
>>
>>
>> On 25 July 2014 15:26, Greg Stein <gs...@gmail.com> wrote:
>>
>>> [adding dev@community, as I believe this should go there...]
>>>
>>> On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert <vh...@gmail.com>
>>> wrote:
>>> >...
>>>
>>> > Hi,
>>> >
>>> > 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 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 problem is, I don't know how I know
>>> > that... I cannot seem to be able to find any official documentation that
>>> > explicitly states it.
>>> >
>>>
>>> That's why you can't find it... I don't recall any such "policy" (over the
>>> past 15+ years I've been around) ... it just isn't a good idea. That's
>>> all.
>>>
>>>
>>> >
>>> > The following link: http://www.apache.org/dev/release.html#what is
>>> > apparently not convincing enough. I'm answered that this concerns our
>>> > own project but that it's fine to do an official release containing
>>> > a snapshot binary.
>>> >
>>>
>>> Well. You need to produce a full set of sources. No binaries. Those
>>> sources
>>> might be by-reference, but you definitely can't release a binary within
>>> your source distribution.
>>>
>>> Even if that other Apache project had a release you're happy with, there
>>> would be a source release available for it.
>>>
>>>
>>> >
>>> > Saying that every binary artefact has to be backed by source code and
>>> > that, in the case of a snapshot, we have to point to some Subversion
>>> > revision number, is apparently not convincing enough either. Despite the
>>> > obvious dependency nightmare that that would cause to users (and, in
>>> > particular, Maven users and Linux distributions).
>>> >
>>>
>>> Pause. This is not negotiable. You *must* have a source release. If you do
>>> that through a signed tarball, or through a git tag, or a Subversion
>>> revision number ... all of these identify a *specific* set of source code.
>>> That satisfies the need.
>>>
>>> You raise some concerns about nightmares... sure. Telling users "you must
>>> get r123 of /some/path, for $LIBRARY" is not exactly friendly. BUT: it
>>> satisfies all release requirements. It will specify the exact dependency.
>>> Good to go.
>>>
>>>
>>>
>>> >
>>> > Does anybody have any official reference to point at, that I may have
>>> > missed? More convincing arguments, legal reasons (should I forward to
>>> > legal-discuss@)?
>>>
>>>
>>> Much of this kind of stuff is "institutional knowledge" because having to
>>> write down "rules" and "procedures" just sucks. It is such a rare event,
>>> that it is best to leave it for the particular situation.
>>>
>>> There are no legal ramifications, if you're talking about a sibling Apache
>>> project.
>>>
>>> Now... you *should not* do any sort of release of a sibling. That will
>>> screw over that community. (version skew, unsupported bits, issue
>>> tracking,
>>> blah blah)
>>>
>>> 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.
>>>
>>> Cheers,
>>> -g
>>>
>>
>>

Re: Non-released Dependencies

[Greg Stein <gs...@gmail.com>]

Agreed that #2 is best.

(and I'll also note I was a bit slack with some commentary; releases need
to be signed, so a path/revision or git-tag is not necessarily a true
release; just trying to get across that you need a *specific* set of source
for a dependency)

Seems that Andreas is going to explore some options at dev@pdfbox.

Cheers,
-g



On Fri, Jul 25, 2014 at 9:34 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> I think the key bit here is that releases of Apache projects must have an
> associated source release and have been voted on by the PMC making the
> release.
>
> If the project you depend on is an independent project, you need to
> remember that their -SNAPSHOT build is *not* a release. Therefore you need
> it to become a release to include it.
>
> You therefore have three choices:
>
> 1. Fork the code into your project and do a big-bang release... a rude
> option but once it's in your project your PMC can vote to release it.
>
> 2. Join the dependent project and help them get to a release
>
> 3. Find somebody outside the ASF (or at a minimum not wearing an ASF hat)
> and get them to fork the code you want and release that. Then you can
> depend on the non-ASF fork of the ASF project... again a rude option, but
> perhaps less so than #1
>
> I vote you go for #2. It plays best with community which is what we are
> here to foster
>
>
> On 25 July 2014 15:26, Greg Stein <gs...@gmail.com> wrote:
>
>> [adding dev@community, as I believe this should go there...]
>>
>> On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert <vh...@gmail.com>
>> wrote:
>> >...
>>
>> > Hi,
>> >
>> > 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 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 problem is, I don't know how I know
>> > that... I cannot seem to be able to find any official documentation that
>> > explicitly states it.
>> >
>>
>> That's why you can't find it... I don't recall any such "policy" (over the
>> past 15+ years I've been around) ... it just isn't a good idea. That's
>> all.
>>
>>
>> >
>> > The following link: http://www.apache.org/dev/release.html#what is
>> > apparently not convincing enough. I'm answered that this concerns our
>> > own project but that it's fine to do an official release containing
>> > a snapshot binary.
>> >
>>
>> Well. You need to produce a full set of sources. No binaries. Those
>> sources
>> might be by-reference, but you definitely can't release a binary within
>> your source distribution.
>>
>> Even if that other Apache project had a release you're happy with, there
>> would be a source release available for it.
>>
>>
>> >
>> > Saying that every binary artefact has to be backed by source code and
>> > that, in the case of a snapshot, we have to point to some Subversion
>> > revision number, is apparently not convincing enough either. Despite the
>> > obvious dependency nightmare that that would cause to users (and, in
>> > particular, Maven users and Linux distributions).
>> >
>>
>> Pause. This is not negotiable. You *must* have a source release. If you do
>> that through a signed tarball, or through a git tag, or a Subversion
>> revision number ... all of these identify a *specific* set of source code.
>> That satisfies the need.
>>
>> You raise some concerns about nightmares... sure. Telling users "you must
>> get r123 of /some/path, for $LIBRARY" is not exactly friendly. BUT: it
>> satisfies all release requirements. It will specify the exact dependency.
>> Good to go.
>>
>>
>>
>> >
>> > Does anybody have any official reference to point at, that I may have
>> > missed? More convincing arguments, legal reasons (should I forward to
>> > legal-discuss@)?
>>
>>
>> Much of this kind of stuff is "institutional knowledge" because having to
>> write down "rules" and "procedures" just sucks. It is such a rare event,
>> that it is best to leave it for the particular situation.
>>
>> There are no legal ramifications, if you're talking about a sibling Apache
>> project.
>>
>> Now... you *should not* do any sort of release of a sibling. That will
>> screw over that community. (version skew, unsupported bits, issue
>> tracking,
>> blah blah)
>>
>> 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.
>>
>> Cheers,
>> -g
>>
>
>

Re: Non-released Dependencies

[Greg Stein <gs...@gmail.com>]

Agreed that #2 is best.

(and I'll also note I was a bit slack with some commentary; releases need
to be signed, so a path/revision or git-tag is not necessarily a true
release; just trying to get across that you need a *specific* set of source
for a dependency)

Seems that Andreas is going to explore some options at dev@pdfbox.

Cheers,
-g



On Fri, Jul 25, 2014 at 9:34 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> I think the key bit here is that releases of Apache projects must have an
> associated source release and have been voted on by the PMC making the
> release.
>
> If the project you depend on is an independent project, you need to
> remember that their -SNAPSHOT build is *not* a release. Therefore you need
> it to become a release to include it.
>
> You therefore have three choices:
>
> 1. Fork the code into your project and do a big-bang release... a rude
> option but once it's in your project your PMC can vote to release it.
>
> 2. Join the dependent project and help them get to a release
>
> 3. Find somebody outside the ASF (or at a minimum not wearing an ASF hat)
> and get them to fork the code you want and release that. Then you can
> depend on the non-ASF fork of the ASF project... again a rude option, but
> perhaps less so than #1
>
> I vote you go for #2. It plays best with community which is what we are
> here to foster
>
>
> On 25 July 2014 15:26, Greg Stein <gs...@gmail.com> wrote:
>
>> [adding dev@community, as I believe this should go there...]
>>
>> On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert <vh...@gmail.com>
>> wrote:
>> >...
>>
>> > Hi,
>> >
>> > 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 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 problem is, I don't know how I know
>> > that... I cannot seem to be able to find any official documentation that
>> > explicitly states it.
>> >
>>
>> That's why you can't find it... I don't recall any such "policy" (over the
>> past 15+ years I've been around) ... it just isn't a good idea. That's
>> all.
>>
>>
>> >
>> > The following link: http://www.apache.org/dev/release.html#what is
>> > apparently not convincing enough. I'm answered that this concerns our
>> > own project but that it's fine to do an official release containing
>> > a snapshot binary.
>> >
>>
>> Well. You need to produce a full set of sources. No binaries. Those
>> sources
>> might be by-reference, but you definitely can't release a binary within
>> your source distribution.
>>
>> Even if that other Apache project had a release you're happy with, there
>> would be a source release available for it.
>>
>>
>> >
>> > Saying that every binary artefact has to be backed by source code and
>> > that, in the case of a snapshot, we have to point to some Subversion
>> > revision number, is apparently not convincing enough either. Despite the
>> > obvious dependency nightmare that that would cause to users (and, in
>> > particular, Maven users and Linux distributions).
>> >
>>
>> Pause. This is not negotiable. You *must* have a source release. If you do
>> that through a signed tarball, or through a git tag, or a Subversion
>> revision number ... all of these identify a *specific* set of source code.
>> That satisfies the need.
>>
>> You raise some concerns about nightmares... sure. Telling users "you must
>> get r123 of /some/path, for $LIBRARY" is not exactly friendly. BUT: it
>> satisfies all release requirements. It will specify the exact dependency.
>> Good to go.
>>
>>
>>
>> >
>> > Does anybody have any official reference to point at, that I may have
>> > missed? More convincing arguments, legal reasons (should I forward to
>> > legal-discuss@)?
>>
>>
>> Much of this kind of stuff is "institutional knowledge" because having to
>> write down "rules" and "procedures" just sucks. It is such a rare event,
>> that it is best to leave it for the particular situation.
>>
>> There are no legal ramifications, if you're talking about a sibling Apache
>> project.
>>
>> Now... you *should not* do any sort of release of a sibling. That will
>> screw over that community. (version skew, unsupported bits, issue
>> tracking,
>> blah blah)
>>
>> 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.
>>
>> Cheers,
>> -g
>>
>
>

Re: Non-released Dependencies

[Stephen Connolly <st...@gmail.com>]

I think the key bit here is that releases of Apache projects must have an
associated source release and have been voted on by the PMC making the
release.

If the project you depend on is an independent project, you need to
remember that their -SNAPSHOT build is *not* a release. Therefore you need
it to become a release to include it.

You therefore have three choices:

1. Fork the code into your project and do a big-bang release... a rude
option but once it's in your project your PMC can vote to release it.

2. Join the dependent project and help them get to a release

3. Find somebody outside the ASF (or at a minimum not wearing an ASF hat)
and get them to fork the code you want and release that. Then you can
depend on the non-ASF fork of the ASF project... again a rude option, but
perhaps less so than #1

I vote you go for #2. It plays best with community which is what we are
here to foster


On 25 July 2014 15:26, Greg Stein <gs...@gmail.com> wrote:

> [adding dev@community, as I believe this should go there...]
>
> On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert <vh...@gmail.com>
> wrote:
> >...
>
> > Hi,
> >
> > 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 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 problem is, I don't know how I know
> > that... I cannot seem to be able to find any official documentation that
> > explicitly states it.
> >
>
> That's why you can't find it... I don't recall any such "policy" (over the
> past 15+ years I've been around) ... it just isn't a good idea. That's all.
>
>
> >
> > The following link: http://www.apache.org/dev/release.html#what is
> > apparently not convincing enough. I'm answered that this concerns our
> > own project but that it's fine to do an official release containing
> > a snapshot binary.
> >
>
> Well. You need to produce a full set of sources. No binaries. Those sources
> might be by-reference, but you definitely can't release a binary within
> your source distribution.
>
> Even if that other Apache project had a release you're happy with, there
> would be a source release available for it.
>
>
> >
> > Saying that every binary artefact has to be backed by source code and
> > that, in the case of a snapshot, we have to point to some Subversion
> > revision number, is apparently not convincing enough either. Despite the
> > obvious dependency nightmare that that would cause to users (and, in
> > particular, Maven users and Linux distributions).
> >
>
> Pause. This is not negotiable. You *must* have a source release. If you do
> that through a signed tarball, or through a git tag, or a Subversion
> revision number ... all of these identify a *specific* set of source code.
> That satisfies the need.
>
> You raise some concerns about nightmares... sure. Telling users "you must
> get r123 of /some/path, for $LIBRARY" is not exactly friendly. BUT: it
> satisfies all release requirements. It will specify the exact dependency.
> Good to go.
>
>
>
> >
> > Does anybody have any official reference to point at, that I may have
> > missed? More convincing arguments, legal reasons (should I forward to
> > legal-discuss@)?
>
>
> Much of this kind of stuff is "institutional knowledge" because having to
> write down "rules" and "procedures" just sucks. It is such a rare event,
> that it is best to leave it for the particular situation.
>
> There are no legal ramifications, if you're talking about a sibling Apache
> project.
>
> Now... you *should not* do any sort of release of a sibling. That will
> screw over that community. (version skew, unsupported bits, issue tracking,
> blah blah)
>
> 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.
>
> Cheers,
> -g
>

Re: Non-released Dependencies

[Andreas Lehmkuehler <an...@lehmi.de>]

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. We are talking about FontBox which is part of the PDFBox 
project. We don't have any difficulties to release a new version. We are working 
on a new major release containing a lot of new stuff and refactorings. Some of 
them are within FontBox but most are within the core component itself. We are 
planning to cut a release in the late summer but we can't guarantee that as 
there are still a lot of things to do. Any help is welcome, but most of the 
stuff isn't about FontBox anymore but the PDF spec and java rendering stuff.

Saying that, I'm afraid the FOP guys have to fork FontBox if they are in a hurry.

> Cheers,
> -g

BR
Andreas Lehmkühler, PDFBox Chair


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: Non-released Dependencies

[Matt Hogstrom <ma...@hogstrom.org>]

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
matt@hogstrom.org
+1-919-656-0564
PGP Key: 0x0F143BC1

"Aut Inveniam Viam Aut Faciam" translated -
"I shall either find a way or make one."

The phrase has been attributed to Hannibal; when his generals told him it was impossible to cross the Alps by elephant,

On Jul 25, 2014, at 10:26 AM, Greg Stein <gs...@gmail.com> wrote:

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

Re: Non-released Dependencies

[Stephen Connolly <st...@gmail.com>]

I think the key bit here is that releases of Apache projects must have an
associated source release and have been voted on by the PMC making the
release.

If the project you depend on is an independent project, you need to
remember that their -SNAPSHOT build is *not* a release. Therefore you need
it to become a release to include it.

You therefore have three choices:

1. Fork the code into your project and do a big-bang release... a rude
option but once it's in your project your PMC can vote to release it.

2. Join the dependent project and help them get to a release

3. Find somebody outside the ASF (or at a minimum not wearing an ASF hat)
and get them to fork the code you want and release that. Then you can
depend on the non-ASF fork of the ASF project... again a rude option, but
perhaps less so than #1

I vote you go for #2. It plays best with community which is what we are
here to foster


On 25 July 2014 15:26, Greg Stein <gs...@gmail.com> wrote:

> [adding dev@community, as I believe this should go there...]
>
> On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert <vh...@gmail.com>
> wrote:
> >...
>
> > Hi,
> >
> > 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 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 problem is, I don't know how I know
> > that... I cannot seem to be able to find any official documentation that
> > explicitly states it.
> >
>
> That's why you can't find it... I don't recall any such "policy" (over the
> past 15+ years I've been around) ... it just isn't a good idea. That's all.
>
>
> >
> > The following link: http://www.apache.org/dev/release.html#what is
> > apparently not convincing enough. I'm answered that this concerns our
> > own project but that it's fine to do an official release containing
> > a snapshot binary.
> >
>
> Well. You need to produce a full set of sources. No binaries. Those sources
> might be by-reference, but you definitely can't release a binary within
> your source distribution.
>
> Even if that other Apache project had a release you're happy with, there
> would be a source release available for it.
>
>
> >
> > Saying that every binary artefact has to be backed by source code and
> > that, in the case of a snapshot, we have to point to some Subversion
> > revision number, is apparently not convincing enough either. Despite the
> > obvious dependency nightmare that that would cause to users (and, in
> > particular, Maven users and Linux distributions).
> >
>
> Pause. This is not negotiable. You *must* have a source release. If you do
> that through a signed tarball, or through a git tag, or a Subversion
> revision number ... all of these identify a *specific* set of source code.
> That satisfies the need.
>
> You raise some concerns about nightmares... sure. Telling users "you must
> get r123 of /some/path, for $LIBRARY" is not exactly friendly. BUT: it
> satisfies all release requirements. It will specify the exact dependency.
> Good to go.
>
>
>
> >
> > Does anybody have any official reference to point at, that I may have
> > missed? More convincing arguments, legal reasons (should I forward to
> > legal-discuss@)?
>
>
> Much of this kind of stuff is "institutional knowledge" because having to
> write down "rules" and "procedures" just sucks. It is such a rare event,
> that it is best to leave it for the particular situation.
>
> There are no legal ramifications, if you're talking about a sibling Apache
> project.
>
> Now... you *should not* do any sort of release of a sibling. That will
> screw over that community. (version skew, unsupported bits, issue tracking,
> blah blah)
>
> 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.
>
> Cheers,
> -g
>

Re: Non-released Dependencies

[Matt Hogstrom <ma...@hogstrom.org>]

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
matt@hogstrom.org
+1-919-656-0564
PGP Key: 0x0F143BC1

"Aut Inveniam Viam Aut Faciam" translated -
"I shall either find a way or make one."

The phrase has been attributed to Hannibal; when his generals told him it was impossible to cross the Alps by elephant,

On Jul 25, 2014, at 10:26 AM, Greg Stein <gs...@gmail.com> wrote:

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