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

<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