Within Felix we have “subprojects” that consist of one or more bundles and I would argue that they are always released together. This does not mean that for every release, every bundle needs to change, sometimes only a subset of the released bundles change.
So I would definitely argue against getting a Git repository per bundle. Per subproject sounds like the right granularity to me. Regarding Maven I don’t have much experience on how to set that up with Git. Note that not all subprojects use Maven. Specifically the “dependency manager” uses a gradle/bndtools based setup. We could easily move that to its own Git repository. It is already setup for that. In general I like Git, and outside of the Apache projects I’m involved in I almost exclusively use it, but I’m +0 on making a switch because it’s also a lot of work and I don’t think the benefits are huge. If it works, don’t fix it. :) Greetings, Marcel On 24 October 2015 at 11:06:02, Benson Margulies ([email protected]) wrote: Here's the basic issue. The maven-release-plugin doesn't always work with git when the pom you are releasing is not the top of the repository. I put a great deal of work into fixing it, and yet others continue to report problems. (It works for my favorite test case.) So, the conservative strategy is to put each group that are released together into a repo. As far as migration, INFRA only understands 'one big flip.' That offers us two choices if our goal is to subdivide: 1: Let infra do the flip, and then gradually get new repos and move some things into them. 2: Do our own migration: one by one, get infra to make new, empty, repos, and use the existing mirror repo as a source to push the pieces into them. I don't see much value in item #1 over item #2. So I'd propose to start by asking infra for a repo for the overall parent pom, which I think needs to live in a repo by itself (that's how we do it at Maven). Once we have released the pom from there, we can migrate others in whatever grouping we prefer. As the new committer here, I have to ask: what decision-making process would be good? On Sat, Oct 24, 2015 at 1:00 AM, David Jencks <[email protected]> wrote: > YAY!! > > as you can tell, I’m in favor of it. > > I think that 1 repo per project may be too small. For instance I think it > makes sense to have one repo for the 3 gogo projects, even though they are > released separately. I think soon there will be at least 4 scr projects and > I’d like them to be in 1 repo. > > Do you know how infra feels about gradual migration? Are they fine with it or > do they prefer all-at-once? > > thanks > david jencks > >> On Oct 23, 2015, at 10:36 PM, Benson Margulies <[email protected]> wrote: >> >> >> There was some discussion a while back about git, which I recall >> (perhaps inaccurately) as vaguely positive. It's a lot easier if each >> releasable thing gets its own git repo. >> >> How do folks feel about starting with a migration of the bundle plugin? >> >> --benson >
