Hi, We're at a point where we're considering releasing the 1.0.0 for the Sling IDE Tooling for Eclipse. Leaving the technical considerations aside, I'd like to make sure the legal requirements for the release are met.
While the build is Maven-based, it's mainly driven by Tycho [1], which does a fantastic job of wrapping the Eclipse toolchain inside Maven, but does not always play nice with other plugins. For instance, we can't use the source and javadoc plugins as inherited from the ASF/Sling parent pom, or use the maven-release-plugin, see [2] . Because of that, I'm trying to get a sense of the minimal requirements to getting a release out. I'll try to split the release deliverables a bit: 1. End-user deliverables, uploaded to dist.apache.org - a zipped Eclipse update site, uploaded to https://dist.apache.org/repos/dist/release/sling/ - a unzipped p2 Eclipse update site, uploaded to https://dist.apache.org/repos/dist/release/sling/eclipse/ - the Eclipse features contain the Apache 2.0 license, which is shown to the user when installing, using the regular Eclipse workflow There may be other opinions regarding update site location - I just took the simplest one. But let's discuss that separately if anyone has a different idea. 2. Maven deliverables - multiple jars corresponding to the individual eclipse plug-ins, all gpg-signed - these jars contain the required LICENSE and NOTICE files, verified during the build by the maven-ianal-plugin 3. Source deliverables - a single zipped file, built from the tag and gpg-signed. GIven that, is it possible to start the release vote based on the source deliverables, and when that is successful upload the end-user deliverables on dist.apache.org? Or do we have to hold the vote on the binaries? Thanks, Robert [1]: http://eclipse.org/tycho/ [2]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=398061 -- http://robert.muntea.nu/
