You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@gmail.com> on 2014/06/05 10:56:48 UTC

Release requirements - Sling IDE Tooling 1.0.0

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/

Re: Release requirements - Sling IDE Tooling 1.0.0

Posted by Robert Munteanu <ro...@apache.org>.
Just to answer myself, according to [1]

"All releases are in the form of the source materials needed to make
changes to the software being released".

Robert

[1]: https://www.apache.org/dev/release.html#what

On Thu, Jun 5, 2014 at 11:56 AM, Robert Munteanu
<ro...@gmail.com> wrote:
> 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/