celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: [DISCUSS] next Celix release
Date Sun, 07 Jul 2013 19:05:59 GMT
On May 30, 2013, at 9:55 AM, Alexander Broekhuis <a.broekhuis@gmail.com> wrote:

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

That last part is true, once you vote on something, you cannot change it anymore, and voting
on 1.0RC and then 1.0 (with the version number being the only change) sounds like a waste.

There are no rules for versioning, but I would keep things simple. Vote for "1.0" or whatever
version number you as a community feel is appropriate. The worst thing that can happen is
that it fails, in which case you bump the version number and try again.

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

Project wise, Celix probably resembles Felix the most. Here we have a trunk with directories
for each "module". Modules consist of one or more related bundles, and we release modules
individually (or sometimes a few modules together). Every bundle within a module is versioned
individually. That is not a problem for a release (having different versions in one release).

In ACE we do it differently. ACE is an application, built out of OSGi components, and we decided
to release it as a whole, so all bundles at once.

Remember, in the end, Apache is all about doing *source* releases. That's also what you vote
on. All binary releases are for convenience only (you see many projects vote on source + binary
artifacts in one go).

With my "personal hat" on, I would say: keep it simple, just release everything everytime
for now and start worrying about separating the code into modules later. For now it probably
creates a lot of extra work, voting for all the parts.

Greetings, Marcel

View raw message