Ask Your Question
4

Is the 'one-version-per-repo' limitation with Bloom, GIT only?

asked 2013-06-25 00:21:04 -0600

gvdhoorn gravatar image

updated 2013-06-25 04:44:29 -0600

In the "Releasing a new version of a catkin Package" [1] tutorial for Bloom, the following statement can be found under "1. Preparing the Upstream Repository":

Even if you do not use this tool, you must have one or more valid package.xml(s) with the same version and a matching tag in your upstream repository.

Since one cannot tag only part of a GIT repository, this seems to imply that all packages in a repository must be released with the same version. The Groovy wikipage [2] states the following:

bloom allows a source code repository to contain any number of packages, related or not. The only caveat to having multiple packages in a single repository is that they must be released with a common version number, i.e. one release version number per repository.

which seems to confirm this.

I'm wondering whether this limitation is due to the use of GIT as an upstream repository, or if this is the result of a limitation in Bloom (or I could also be misunderstanding something).

Would using a subversion repository as an upstream work around this (ie: by tagging individual package directories)?

For my particular use case I'd like to be able to release packages independently, even if they share the same repository. I'd like to be able to add and change packages without having to re-release any of the already existing or unchanged ones (while taking dependencies into account of course). I'm getting the impression from the documentation that this is not possible, at least not with the Bloom & Catkin combination.

Is creating separate repositories for packages that should be independendently 'releasable' the only option?

  1. www.ros.org/wiki/bloom/Tutorials/ReleaseCatkinPackage
  2. ros.org/wiki/groovy
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2013-06-25 04:35:53 -0600

Dirk Thomas gravatar image

The limitation affects any VCS which tags a repository globally which implies Git, Hg, etc. The reason is simply that those do not provide a way to tag/clone only parts of the repo.

For SVN this limitation does not apply since you can structure a SVN repo in a away that it contains separate projects where each on has its own trunk/branches/tags structure and a user can checkout any of those individually.

Consider telling a user you have to clone repo foo in version 1.1.1 but you only need the package foo1 in there but also clone repo foo again in version 1.2.3 but only for the package foo1 and foo2.

So you listed your options correctly: either split the packages into multiple Git repos, release them all at once from a single repo, or use SVN to keep them in one repo but tag them individually.

Just as a side note: the task of re-releasing packages is very easy nowadays and only takes an extremely short amount of time.

edit flag offensive delete link more

Comments

1

Re-releasing is efficient with Bloom, I agree, but I'd like to avoid the actual build step and the fact that my users receive update notifications for packages which have essentially not changed. Unless I'm mistaken, every released package gets build, whether it has actual changes or not.

gvdhoorn gravatar imagegvdhoorn ( 2013-06-25 04:39:43 -0600 )edit

That is true. But until ROS also rebuilds every downstream package when a package changes that might be pretty neglectable.

Dirk Thomas gravatar imageDirk Thomas ( 2013-06-25 06:28:08 -0600 )edit

Sometimes it is useful to put a metapackage and all its subordinate packages in a single repository, always releasing them together. But, if your repository contains only loosely-related packages, you might choose to divide them into separate repositories.

joq gravatar imagejoq ( 2013-06-25 07:57:40 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2013-06-25 00:21:04 -0600

Seen: 256 times

Last updated: Jun 25 '13