|
|
Martin J. Laubach wrote:
> What is the correct way of having a shared package? Say I have a
> generic "Foo-Support" package that I want to have in my
> application A and application B?
> Do I have two Bundles A and B and
> somehow add Foo-Support to both of them or will having the same package
> (perhaps with different versions) in different Bundles wreak havoc?
You can do this and it won't wreak havoc on your image, however if you
load both bundles in a single image and they specify different versions
of the package then you will end up with one of the bundles being
(marked as) changed since only one version of the package can be loaded
at a time.
The downshot is that every time you fix a bug in the package you will
need to update all the bundles, regardless of whether they are in your
image or not.
> Or
> perhaps I should add Foo-Support as prereq to A and B?
That is by far the easiest, especially when you bug-fix the package the
latest version will be used next time you load the bundle into a clean
image.
The downshot here is that you don't get a 'stable' build: if you load an
older version of the bundle for maintenance purposes you will get too
new a version of your package.
>
> Comments? I guess I'm slightly confused by the Store versioning model.
You can combine both methods in your development process:
--use only packages and prereqs (no bundles at all) during mainline
development, it is now easy to create a development image: load the top
level package (we use special empty packages with only prereqs for this
purpose).
--stuff all your used packages into a single bundle when you do a
release, you can load this bundle when you want to do maintenance on a
released version of your product.
If you develop with multiple people then bundles rapidly turn into a
versioning bottleneck (even more so when using nested bundles) we use
lineups as mentioned in the 'working with multiple repositories' thread
to overcome this problem.
HTH,
Reinout
-------
|
Locked
