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]: > > http://markmail.org/message/fc57catu7yfnzzho > > [2]: > > http://en.wikipedia.org/wiki/Software_versioning > > [3]: > > http://markmail.org/message/owr2dz27bhfafm6d > > > > Kind regards, > > Jeroen Kouwer > > -- > > :wq! > > > -- Met vriendelijke groet, Alexander Broekhuis
