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 a.broekhuis@gmail.com
 designates 209.85.217.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <b1f56382dcba5e7fb9acc8e8be1221ef.squirrel@46.19.35.7>
References: 
 <CAPhv5g_CgVUdu9w1yw5GLPXTS+C_b3H4ZCnMKo9g5MfAL0L08Q@mail.gmail.com>
	<b1f56382dcba5e7fb9acc8e8be1221ef.squirrel@46.19.35.7>
Date: Thu, 30 May 2013 09:55:31 +0200
Message-ID: 
 <CA+T-u8fF=7JXP0n9aN6F8_V4NubgcSROFWZW6jVSvmg=CostNQ@mail.gmail.com>
Subject: Re: [DISCUSS] next Celix release
From: Alexander Broekhuis <a.broekhuis@gmail.com>
To: celix-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=001a11c3772c90ded404ddead2ba

--001a11c3772c90ded404ddead2ba
Content-Type: text/plain; charset=ISO-8859-1

Hi,

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?
>

There is a duplicate status. If you see a duplicate feel free to comment on
one of the two so we can mark one as duplicate.

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.
>
>
I am fine with a 1.0RC, but from a procedural point of view I would like to
make it 1.0 without the suffix. The reason being.. That if we do go from
1.0RC to 1.0 it is a new release and we do need to do a new vote etc. For
the previous release the vote was somewhat troublesome, since there have to
be enough votes etc.

If we do want to make an actual 1.0rc vote, we do need to accept that there
will be a vote shortly after that release for a 1.0 release.

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.


This is more or less already possible. When a certain module is enabled all
required dependencies are also enabled. So for example building Remote
Services also enables the Framework.
The split isn't on bundle level, but more on a deployment level, ie Remote
Services is one module and has multiple bundles.

But:


> 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?
>

When looking at OSGi and modularity, I'd like to see a separate release for
each bundle. This makes sense, since each bundle has an own version etc.
This doesn't necessarily mean that subprojects should be in another trunk,
but there ha been some discussion in the past for other OSGi projects where
Marcel is also involved in. So maybe he can provide some insight in the
best way to solve this...

-- 
Met vriendelijke groet,

Alexander Broekhuis

--001a11c3772c90ded404ddead2ba--