celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: Working towards a next release
Date Sat, 17 Nov 2012 20:12:24 GMT
Hi All,

On Thu, Nov 15, 2012 at 3:49 PM, Alexander Broekhuis

> Hi all,
> Even though the first release hasn't been accepted, I do like to know what
> a next release should fix or implement.
> The first release was done mostly for creating a release. This is important
> for the incubator, but maybe even more to get peoples attention. Having a
> release makes it easier to try/test Celix.
> But for the next release I think we can focus more on the content of the
> release. Some topics I can think of:
> * Finish APR usage in the framework. APR is already being used for the most
> part of the framework, but still not all code has been updated.
> * APR usage in bundle can also be updated. Some bundles do use it, but most
> not yet.
> * Remote Services implementation needs work. Things like protocol usage,
> pluggable solution for different protocols, tests etc.
> Besides technical stuff, there are also some other things we should start
> doing:
> * Track issues in Jira
>   In the past we did use Jira for some bugs/issues, but mostly ignored it
> when working on the source. For a next release I think we should start
> using Jira to keep track of progress and a changelog.
> * Update documentation
>   We need more documentation, on building and using Celix, but also on the
> design/implementation as well ass release guides etc.
> Any/All ideas are welcome! Nothing has been decided, so all options are
> open.

I agree with all the topics mentioned. Personally I think we can gain much
by improving remote services and updating the documentation so that it is
easier to get started with Apache Celix. There is nice page for a hello
world example in Apache Celix, but a page how get a CMake build environment
working separated from Apache Celix is missing.

I also think is a good idea to get the naming and typedefs straight. For
example we now have:
typedef struct listener_hook *listener_hook_t;
typedef struct bundle * BUNDLE;

> Just a reminder, if the first release needs to be redone, a new release
> will be made with the current state of the code. So "next release"
> doesn't necessarily mean 0.0.2 or even 0.0.3...
> --
> Met vriendelijke groet,
> Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message