[cdt-dev] Managed Build System Versioning Strategy

[Sean Evoy <sevoy@xxxxxxxxxx>]

OK,
Here, as promised, is my suggestion
for versioning the managed build system. 

The ManagedBuildManager is the heart
of the build system in terms of reading in the manifest where the tool
definitions are located (plugin.xml) and loading build information for
existing projects (.cdtbuild). It needs to know whether or not it can read
the a given manifest or project file and make sense of what it finds. This
will be very important going forward, since we know that the schema for
defining tools is not sufficient for everyone's needs. As the schema changes,
so too will the manifest and, by extension, the project files.

I propose creating a hard-coded PluginVersionIdentifier
in the ManagedBuildManager. A version identifier is comprised of a major,
minor, and service component (all integers), and a string qualifier. For
example, reading the version from an integration build would get an identifier
like 2.0.0."200404140811". For simplicity, the hard-coded version
identifier in the build manager will not have a qualifier, just the major,
minor, and service components. The version element is the only thing that
has to be manually kept up-to-date by the development team. I realize that
hard-coding is a big, red flag for most people, but in order to test, the
info has to be stored somewhere. I am open to alternative locations for
the version info, of course.

When the ManagedBuildManager is asked
to load the tool definitions, it will ask the plugin what version it is
(this is encoded in the plugin manifest and easily available through the
plugin descriptor). If the hard-coded version is compatible with the version
coming back from the plugin it will load it. If not, it will throw a build
exception. Really, it is a stretch to even imagine that this will ever
happen, but you never know ....

Project build settings are also persisted
in a file. The build manager will write out a ProcessingInstruction containing
the string equivalent of its hard-coded version. When a project file is
read in some time in the future, the string will be compared to the hard-coded
version, and  one of three things will happen. If the file version
is greater than the hard-coded version in the build manager reading the
file, it will throw a build exception. If the file version is compatible,
it will read the file. If the file version is lower, it will call a project
file conversion routine to update the file (this might be a NOP if there
is no substantive changes between the two versions) and then read it.

Issues in no particular order:

• The absence of a ProcessingInstruction indicates that a file is from CDT 1.2.x and needs to be upgraded.
• The only project files we have to worry about right now are 1.2.x files, so we can defer the discussion of our post-2.0 project file upgrade strategy if we agree that the underlying logic/implementation is sufficient.
• As we move forward, we may have to impose a limit on how many version we will upgrade (i.e. by the time 4.0 rolls around will we have to be able to load 1.2.x project files?)
• Should we update project files silently or ask the user. A refusal results in not reading in the settings (but the project will still be in the workspace). Acceptance means the cdtbuild file is updated.
• Should the project converter be defined as an executable extension in the manifest (so people implementing a toolchain can supply their own for their customizations).

Please let me know if there is anything
critical that I have overlooked and feel free to supply any feedback you
have. Of course, time is of the essence .... 

Thanks,

Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada