community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Non-released Dependencies
Date Fri, 25 Jul 2014 14:26:11 GMT
[adding dev@community, as I believe this should go there...]

On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert <vhennebert@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message