Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <b1f56382dcba5e7fb9acc8e8be1221ef.squirrel@46.19.35.7>
In-Reply-To: 
 <CAPhv5g_CgVUdu9w1yw5GLPXTS+C_b3H4ZCnMKo9g5MfAL0L08Q@mail.gmail.com>
References: 
    <CAPhv5g_CgVUdu9w1yw5GLPXTS+C_b3H4ZCnMKo9g5MfAL0L08Q@mail.gmail.com>
Date: Thu, 30 May 2013 09:40:52 +0200
Subject: Re: [DISCUSS] next Celix release
From: erik@jansman.eu
To: celix-dev@incubator.apache.org
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

> Hi All,
>
>
> Concerning the improvements, I added a list of issues which we
> currently have planned for the next release. I think this also covers
> earlier discussion we had on the mailing list. If I missed something
> or you have a additional request, please feel free to reply to this
> mail.
>
> CELIX-60 to CELIX-69

I have checked this list and it seems complete to me however some of the
issues are duplicate with some older issues. for example CELIX-64 is I
think a duplicate of CELIX-55. Do these issues have to be linked? or is
there a duplicate status for them?

> see JIRA [1] for the detailed descriptions of the issues.
>
>
> We also discussed a version number and although Celix does not - yet -
> cover the whole core OSGi specification; we think Celix offers enough
> - feature wise - as a (micro) service framework for C to consider a
> 1.0 release.
> That said we are unsure whether we first should create a 0.9 release,
> and from there work to 1.0 release, or directly go for a 1.0 release.
> Comments on this are welcome :)

What would be the reason to first go for 0.9? I would prefer a 1.0RC first
and as soon as possible move to the 1.0 instead. First releasing 0.9 might
give the impression of celix not being stable yet.

>
> Lastly we discussed if we want to release everything (framework,
> remote services, device access, dependency manage, etc) or a subset of
> the Celix project. I think it is preferable to release "just" the
> framework, log_writer, log_reader, shell and shell_tui bundle. This
> way we can focus our time more and these parts for a stable, more
> mature release. Any thoughts on this? Also how to technically achieve
> this?

I think to do this it should be possible to build bundles without building
the rest of Celix, I'm unsure if this is possible yet. I also think we
should move the sub-projects out of the trunk if we aren't going to
release everything in one release.

Also selecting the bundles which are going to be part of the main release
would have to be based on what is the functionality we want to offer. Is
it only core functionality for local services and ifso is log_writer and
log_reader part of it or do we want to offer a more "complete" set
including remote services as well?


> Greetings,
> Pepijn
>
> [1] https://issues.apache.org/jira/browse/CELIX
>

Greetings,

Erik