felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: OSGi and Git - what release process, how many repos?
Date Mon, 11 Aug 2014 12:27:46 GMT
After struggling with/trying out the different git apporachs like sub
modules etc, we decided on having a 1:1 mapping between a module (bundle)
and a git repository. If you have more than one module in a git repo,
tagging and branching is not on a per module base but on the set of modules
which can be totally confusing if you have different release cycles for
your modules.
Having this one to one mapping, also allows you to easily find the
repository or the tag of a module as in our case the name of the repository
is the name of the module.

I guess this alone is already a topic where you get a bunch of different
opinions and ways how to do it. While the above works perfectly well for
us, it might be a nightmare for others and vice versa.

When it comes to tooling, we're sold on Maven which works perfectly well
for us and regardless if there are better tools or not, switching would be
way too expensive.

However, the key thing is imho semantic versioning, follow this when it
comes to version your api from the start. This will keep you out of trouble
later on. In my opinion following semantic versioning is more important
than what tool you choose or how you structure your source repositories.


2014-08-11 13:29 GMT+02:00 Christian Schneider <chris@die-schneider.net>:

> Very good question. We have the same issue in Apache Aries and I think it
> is a reason why aries is still on svn.
> So a good solution for the problem of multiple modules with possibly
> different version numbers on git is highly relevant.
> Christian
> Am 11.08.2014 12:25, schrieb Bulu:
>  Hi all
>> I'm new to Git and want to use it for my new OSGi project. The project
>> will be split in some ~20 bundles which are intended to work together and
>> form a single shippable product with a unique release version number.
>> Nonetheless, at a later time, some of these bundles might be used outside
>> of that product in separate projects.
>> I would like to have your experience what works and what doesn't. (links
>> & readings also welcome)
>> First purely OSGi: the full product version 1.0 is comprised of bundles
>> each of which has a different version number in itself. Where do you store
>> that information? Does each bundle get to know that it is part of a parent
>> release 1.0? Is Maven the (only? best?) way to go?
>> The bundles will still be tightly coupled - eg. change the API, change
>> the impl, change all consumers. So is the "typical" release process to have
>> all bundles in -SNAPSHOT and only change that to a valid version when a
>> release is getting prepared?
>> Now I want to use git for this. Do you recommend having
>> 1. one repo per bundle (what tools to use for managing that many repos?)
>> 2. one branch per bundle in a single repo
>> 3. use git submodules
>> 4. other approaches?
>> My "main-line" will probably be latest&greatest of all bundles. I will
>> want to run integration tests which assembles the fully working product and
>> then runs the tests. Are there any advantages or disadvatages to any of the
>> approaches above (eg. for the continuous integration, building from sources
>> etc)?
>> Thanks for your answers.
>>   Philipp
>> PS: I understand my question is not specifically linked to Felix
>> (although, that's what I use). If you consider this too much off-topic,
>> please recommend another forum.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
> --
>  Christian Schneider
> http://www.liquid-reality.de
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org

Carsten Ziegeler
Adobe Research Switzerland

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