Thanks Seth,
Branching a code base is one of the major work flows where the current
version design creates a mess.
Other examples include
1) Annotating a release requires a code change and a rebuild. Forcing a
QA check on the binary forcing the implementation of a release candidate
process. The release candidate process basically means you are going to
say something is a release before you know it is a release because you
can't say something is a release after you know it is a release.
2) Accepting dependencies. If my project depends on a SNAPSHOT I get
their latest and greatest. Which is great I like continually
integrating with my dependencies because we find problems early and fix
them cheaply. The problem is that when I find out a dependency has
broken my project I have to wait for them to fix it before my project is
fixed. Add a bunch a dependencies and continual integration feels more
like continual breakage. I want to be able to test their drops and if
they pass use them.
3) Transitive dependencies. A good half of my build breakages do not
come from my direct dependencies. Instead their dependencies break.
Without any change in my dependency, the transitive dependencies can
change. My project did not bring these dependencies in, so we have no
familiarity with them or with their developers. Yet because of this
mechanism we end up testing the integration of the transitive dependency
before our dependency has tested the integration. I want to let my
dependency do the integration with new transitive dependencies. When
they are successful then I'll integrate with the both of them.
Mike Power
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
