[DISCUSS] next Celix release

[Pepijn Noltes <pe...@gmail.com>]

Hi All,

Last week Alexander & I met f2f to talk about a next Celix release. We
talked about what improvements we think is needed for the next
release, what version number we think the the next release should have
and if we want to release the whole project or just a set of sub
projects.

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-69 Check for win32 (visual studio) support
CELIX-68 Check for memory leaks
CELIX-67 Check for dependency manager usage
CELIX-66 Refactor shell service struct
CELIX-65 add bonjour support for Remote Service Admin
CELIX-64 Add support for ccputest
CELIX-63 make cmake directory useable for custom bundle projects
CELIX-62 rename suffix of pointer type from _t to _pt
CELIX-61 use apr calls instead of malloc, free, pthreads, etc
CELIX-60 Support framework embedding

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 :)


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?

Greetings,
Pepijn

[1] https://issues.apache.org/jira/browse/CELIX

Re: [DISCUSS] next Celix release

[Alexander Broekhuis <a....@gmail.com>]

<snap>


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

Sounds good to me!


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

I think this is key in what we want/need. If it is no problem to have
multiple versions in one release it is really simple to give certain
modules a big bump to 1.0 and leave others at a lower version. This makes
it possible to indicate maturity. Although I personally don't have a
problems with <1.0 version numbers, there are still a lot of
people/companies who do. So for adoption of Celix I think it is good to
have a 1.0 release of the framework and some key bundles.


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

I personally don't have any plans to do binary releases any time soon, and
I know the source is what matters when doing releases. If we intend to do
binary releases as well we need to discuss how this can be done.


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

With above statement about multiple versions in one release, I am in favor
of this!


-- 
Met vriendelijke groet,

Alexander Broekhuis

Re: [DISCUSS] next Celix release

[Marcel Offermans <ma...@luminis.nl>]

On May 30, 2013, at 9:55 AM, Alexander Broekhuis <a....@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 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...

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

Re: [DISCUSS] next Celix release

[Alexander Broekhuis <a....@gmail.com>]

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

Re: [DISCUSS] next Celix release

[er...@jansman.eu]

> 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