|
»
»
« Return to Thread: [vwnc] Bundles
Re: [vwnc] Bundles
by Joachim Geidel-2
::
Rate this Message:
In the project where I am working, we seem to use bundles and
prerequisites more or less the same way as Steve's group.
Steven Kelly schrieb am 14.05.2008 14:02 Uhr:
>> Do you use bundles?
> yes
>> If so, how do you use them, and why?
>
> - To collect our code together in the browsers
Same here. We develop about ten different products with ca. 40
developers, and the product I have worked on has four different variants
(two very similar clients for different user groups, a mobile/offline
version, and a batch processor). There is a group developing basic
libraries, and some products include components from up to three other
products. These components are grouped in bundles, because we usually
want to load all of their packages. If we only need some of them, that
can still be done. The development images typically contains hundreds of
packages in addition to the VisualWorks base. Bundles and sub-bundles
are necessary to be able to navigate in such a large code base, and to
define the contents of product variants in a simple way.
> - To version our code together, and provide a place for an overview of
> all the individual packages' version comments
+1
> - To make loading our code easier (smaller number of components +
> versions)
Definitely. We usually don't define prerequisites at the package level,
except when a package can be used in isolation. We use bundles to keep
related packages together, which also ensures that the have the right
versions loaded - ensuring this in a consistent way with prerequisites
only would be a maintenance nightmare. We use prerequisites at the
bundle level, and the prerequisites are mostly bundles. We have tool
support which updates the prerequisite versions from what's loaded in
the image, which makes baselining very simple.
> - We mostly have bundles that only contain packages, and each package is
> only in one bundle
We have sub-bundles, and usually a package is in only one bundle. There
are a few exceptions, but we try to avoid them.
> - We have a couple of occurrences of a bundle containing (packages and a
> bundle containing packages)
> - We have a couple of occurrences of a package being contained in two
> different bundles
>
> - A bundle's version history may sometimes branch temporarily to allow
> patches to a release, while the main trunk continues with free
> development of the next release
Same here. Sometimes, we also have branches for one or more prototypes,
or for a larger refactoring which is intergrated into the trunk after
maybe several weeks of development. There have been situations where we
had up to four parallel lines of development, and branches of bundle
versions made this easy to manage.
> - We build development and deployment images from a virgin visual.im
> with scripts that load Cincom parcels, reconcile them with our local
> Store, load a few packages from the public Store, and load our app from
> our local Store. For deployment a script then unloads Store and other
> unloadable development packages then runs RTP.
More or less the same here, except that we use a base image with
preloaded and already reconciled parcels, and we don't use the public Store.
> - We have added our own little tools:
+100 ;-)
> - a better list of "More recently published" that filters out packages
> if they can be loaded by loading a bundle shown
> - "Unloaded published items" and "Unloaded recently published items"
> to show 'relevant' new packages or bundles
> - the bundle compare versions dialog has a button "Show version
> comments" that concatenates the version comments of all package changes
> between the bundle versions
Good idea. May we steal it? :-)
> - "reconcile just bundle" to quickly rebase a bundle on a more recent
> published version, without trying to reconcile the code contents of the
> packages
> - "More recently published contents of bundle" that lists only updated
> versions of this bundle or its contents
Same here, plus the option to do this for a configurable list of bundles
which go into a product with a single click, and load what has been
found. With this tool, we have "open configuration maps" - no need to
publish the bundles every time we publish a package, and very easy to
stay up to date. Bundles are only published for baselines, and when
their structure changes (addition/removal of packages). Some teams still
prefer to publish the bundles every time, but this leads to very long
version histories and slows down the load process for updating an image.
>> If setting explicit pre-reqs was easier, would you still use bundles?
>
> Yes. We use pre-reqs very little. Pre-reqs create a network where each
> package carries some of the responsibility, and the result is determined
> at load time. The mechanisms in pre-reqs are not sophisticated enough to
> specify which package and version of it should be loaded under which
> circumstances (e.g. VW version compatibility, platform). Conversely, if
> they were more complicated then getting them right would be harder - at
> least to achieve the desired level of certainty.
+1, see above.
> Pre-reqs work well when there is a large mass of components shared by a
> large mass of users from different organizations, and those users don't
> have many components from outside the shared mass - e.g. Linux OS
> components and standard apps. Bundles (or similar) work better within
> one organization, or where some components are local and some shared
> (e.g. our Store + the public Store).
>
> Travis asked a few more questions, some of them rather leading :-). Yes,
> we used Envy actively 1993-2000, with about a dozen programmers over two
> sites. One of our bundles' structure was defined then, the rest since. I
> feel bundle load order lists are often the simplest and most reliable
> way to sort out load order issues.
I agree, and as I described above, we work along this line.
> I've never noticed that bundles
> suppress package post load actions - is that really true??
I also don't remember such a behavior. I am almost certain that our
application (and JNIPort, which uses bundles, too) wouldn't work if this
were true.
Joachim
_______________________________________________
vwnc mailing list
vwnc@...
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
prerequisites more or less the same way as Steve's group.
Steven Kelly schrieb am 14.05.2008 14:02 Uhr:
>> Do you use bundles?
> yes
>> If so, how do you use them, and why?
>
> - To collect our code together in the browsers
Same here. We develop about ten different products with ca. 40
developers, and the product I have worked on has four different variants
(two very similar clients for different user groups, a mobile/offline
version, and a batch processor). There is a group developing basic
libraries, and some products include components from up to three other
products. These components are grouped in bundles, because we usually
want to load all of their packages. If we only need some of them, that
can still be done. The development images typically contains hundreds of
packages in addition to the VisualWorks base. Bundles and sub-bundles
are necessary to be able to navigate in such a large code base, and to
define the contents of product variants in a simple way.
> - To version our code together, and provide a place for an overview of
> all the individual packages' version comments
+1
> - To make loading our code easier (smaller number of components +
> versions)
Definitely. We usually don't define prerequisites at the package level,
except when a package can be used in isolation. We use bundles to keep
related packages together, which also ensures that the have the right
versions loaded - ensuring this in a consistent way with prerequisites
only would be a maintenance nightmare. We use prerequisites at the
bundle level, and the prerequisites are mostly bundles. We have tool
support which updates the prerequisite versions from what's loaded in
the image, which makes baselining very simple.
> - We mostly have bundles that only contain packages, and each package is
> only in one bundle
We have sub-bundles, and usually a package is in only one bundle. There
are a few exceptions, but we try to avoid them.
> - We have a couple of occurrences of a bundle containing (packages and a
> bundle containing packages)
> - We have a couple of occurrences of a package being contained in two
> different bundles
>
> - A bundle's version history may sometimes branch temporarily to allow
> patches to a release, while the main trunk continues with free
> development of the next release
Same here. Sometimes, we also have branches for one or more prototypes,
or for a larger refactoring which is intergrated into the trunk after
maybe several weeks of development. There have been situations where we
had up to four parallel lines of development, and branches of bundle
versions made this easy to manage.
> - We build development and deployment images from a virgin visual.im
> with scripts that load Cincom parcels, reconcile them with our local
> Store, load a few packages from the public Store, and load our app from
> our local Store. For deployment a script then unloads Store and other
> unloadable development packages then runs RTP.
More or less the same here, except that we use a base image with
preloaded and already reconciled parcels, and we don't use the public Store.
> - We have added our own little tools:
+100 ;-)
> - a better list of "More recently published" that filters out packages
> if they can be loaded by loading a bundle shown
> - "Unloaded published items" and "Unloaded recently published items"
> to show 'relevant' new packages or bundles
> - the bundle compare versions dialog has a button "Show version
> comments" that concatenates the version comments of all package changes
> between the bundle versions
Good idea. May we steal it? :-)
> - "reconcile just bundle" to quickly rebase a bundle on a more recent
> published version, without trying to reconcile the code contents of the
> packages
> - "More recently published contents of bundle" that lists only updated
> versions of this bundle or its contents
Same here, plus the option to do this for a configurable list of bundles
which go into a product with a single click, and load what has been
found. With this tool, we have "open configuration maps" - no need to
publish the bundles every time we publish a package, and very easy to
stay up to date. Bundles are only published for baselines, and when
their structure changes (addition/removal of packages). Some teams still
prefer to publish the bundles every time, but this leads to very long
version histories and slows down the load process for updating an image.
>> If setting explicit pre-reqs was easier, would you still use bundles?
>
> Yes. We use pre-reqs very little. Pre-reqs create a network where each
> package carries some of the responsibility, and the result is determined
> at load time. The mechanisms in pre-reqs are not sophisticated enough to
> specify which package and version of it should be loaded under which
> circumstances (e.g. VW version compatibility, platform). Conversely, if
> they were more complicated then getting them right would be harder - at
> least to achieve the desired level of certainty.
+1, see above.
> Pre-reqs work well when there is a large mass of components shared by a
> large mass of users from different organizations, and those users don't
> have many components from outside the shared mass - e.g. Linux OS
> components and standard apps. Bundles (or similar) work better within
> one organization, or where some components are local and some shared
> (e.g. our Store + the public Store).
>
> Travis asked a few more questions, some of them rather leading :-). Yes,
> we used Envy actively 1993-2000, with about a dozen programmers over two
> sites. One of our bundles' structure was defined then, the rest since. I
> feel bundle load order lists are often the simplest and most reliable
> way to sort out load order issues.
I agree, and as I described above, we work along this line.
> I've never noticed that bundles
> suppress package post load actions - is that really true??
I also don't remember such a behavior. I am almost certain that our
application (and JNIPort, which uses bundles, too) wouldn't work if this
were true.
Joachim
_______________________________________________
vwnc mailing list
vwnc@...
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
« Return to Thread: [vwnc] Bundles
| Free Forum Powered by Nabble | Forum Help |
