Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jukka.zitting@gmail.com
 designates 74.125.82.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2E45169E9A237B4DA78078A68962F9EF0161ACC8@IMCMBX01.MITRE.ORG>
References: <2E45169E9A237B4DA78078A68962F9EF0161ACC8@IMCMBX01.MITRE.ORG>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Tue, 10 Jul 2012 09:20:36 +0200
Message-ID: 
 <CAOFYJNYakiE1E5Jjb-5wkWj-aW9amRwDHQn0Foc8xhj_ryEgkg@mail.gmail.com>
Subject: Re: Celix: A Shepherd's View
To: general@incubator.apache.org
Cc: celix-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On Tue, Jul 10, 2012 at 3:57 AM, Franklin, Matthew B.
<mfranklin@mitre.org> wrote:
> 1) I would recommend trying to accelerate release plans.

Agreed. Is there something in particular that's blocking a release?

> It takes a lot of work up front, but cutting releases is a critical part of incubation.

It's not necessarily even that much work if you're already through IP
clearance, which I believe Celix to be since that's not mentioned in
the report.

Once the IP issues and things like source headers are taken care of,
cutting a release can be as simple as:

    1) tag the latest trunk
    2) export and package the tag
    3) checksum and sign the exported package
    4) conduct the release vote
    5) ship it!

If you're worried about stability of the released codebase, simply
mark the release as unstable (for example with a 0.x version number)
to better manage expectations.

BR,

Jukka Zitting