incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <>
Subject Re: Celix release management/planning
Date Thu, 17 Jan 2013 08:11:10 GMT
Hi all,

> I like this idea.

Me 2, This is a kinda similar to what Sascha proposed earlier in this
thread I think.

> If we keep the date driven releases small (only bug
> fixes) it should be a small effort to release a new version Celix, this
> will help in keeping the work for Celix manageable.

Agreed, making a release isn't a problem at all. For this to work we need
to write down the release procedure, but we already mentioned this during
the vote for the first release.

> On the other hand this
> also gives us the freedom to work on feature and release them when they are
> ready.

To keep things separated this work needs to be done on a branch. This means
we need to merge stuff back and forth, but I don't see that as a problem.

> I do think that if we are ready to release a new Celix features wise
> we should break the date release schedule and postpone a  scheduled date
> release, otherwise we still have a date driven release with the version
> number showing if we have introduced new features.

I am not sure on this one, I don't think it is a problem to introduce new
features using this method on the same schedule as small releases. I do
think however that we need to discuss the versioning a bit further.
There are two things that come to mind:
* Use semantic versioning (looking at the modularity of OSGi I personally
see this as a must)
* Have separate versions for the different parts (the framework, and the
individual bundles).

@Marcel: How do you guys do this with Ace/Felix? Especially since Apache
officially only has source releases?
A possibility I can think of is to have some sort of virtual version for
the entire source package, and have each part have its own version.

> >
> > [1]:
> >
> > [2]:
> >
> > [3]:
> >
> >
> > Kind regards,
> > Jeroen Kouwer
> > --
> > :wq!
> >

Met vriendelijke groet,

Alexander Broekhuis

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