celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Re: [DISCUSS] next Celix release
Date Mon, 08 Jul 2013 06:50:17 GMT
<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

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