Re: Non-released Dependencies
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.conno...@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 gst...@gmail.com wrote: [adding dev@community, as I believe this should go there...] On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert vhenneb...@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
On 28 July 2014 10:20, Greg Stein gst...@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.conno...@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 gst...@gmail.com wrote: [adding dev@community, as I believe this should go there...] On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert vhenneb...@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-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Non-released Dependencies
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-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Non-released Dependencies
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-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Non-released Dependencies
Le 25/07/2014 13:06, Vincent Hennebert a écrit : 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. 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. Just consider the technical aspects of the problem : how do you identify the non-released package ? By a timestamp ? How do you associate this timestamp with some source ? For an external user having some problem with your project, just because there is something wrong in this non-release package, how do you think someone can help debugging the problem ? How do you track the exact code associated with this non-released package? This is just common sense, and anyone who has already worked with non-released/non-trackable packages know exactly what I mean. Otherwise, if common sense is not enough, you can probably use http://incubator.apache.org/guides/releasemanagement.html#best-practice-dependencies, (Where appropriate) check the that the application is built against the correct versions Now, assuming the dependencies are Apache projects, then you can't release them into your own project release, if they aren't themselves released, per http://www.apache.org/dev/release.html#what : Under no circumstances are unapproved builds a substitute for releases. and again, from http://incubator.apache.org/guides/releasemanagement.html#best-practice-dependencies : dependencies should comply with the current apache policy By depending on a non-released component, you are breaking these rules, AFAICT. IMHO, leveraging common-sense should be enough... my2cts - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Non-released Dependencies
On Fri, Jul 25, 2014 at 7:06 AM, Vincent Hennebert vhenneb...@gmail.com wrote: 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. 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. 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. 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). 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@)? There are many topics on which only guidelines exist. In my opinion as an ASF member, this is not one of them. http://www.apache.org/dev/release-publishing.html#what the fundamental requirement for a release is that it consist of the necessary source code to build the project That doesn't just mean building the project at the moment. It means 3 or 5 years down the road. Building against a snapshot isn't reproducible in the long term. If a user at some point cannot change a line of code in your release and recompile the code, you've failed to meet the release requirements. Again, having your release buildable from code is the *ONLY* requirement for a release (other than legally owning the code). You can publish a release which is completely non-functional and unsuitable for the purpose for which it was designed (we hope you will not), but you cannot publish a release which is not buildable from source. As for addressing the specific situation, In order to make an acceptable release against a snapshot, you would need to bundle a buildable version of the snapshot source code (ie, an internal release of that source code) as part of your release. However, since the dependency is on another ASF project, there's really no reason not to just get that other project to create an official release for you. - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Non-released Dependencies
[adding dev@community, as I believe this should go there...] On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert vhenneb...@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
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 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 gst...@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. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Non-released Dependencies
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 gst...@gmail.com wrote: [adding dev@community, as I believe this should go there...] On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert vhenneb...@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
