-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx
[mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf
Of Sean Evoy
Sent: Thursday, April 15, 2004
3:58 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Managed Build
System Versioning Strategy
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.
[Recoskie, Chris]
Being not really familiar with build versioning, I’m
not quite sure how the string identifier is meant to be interpreted…
I’m guessing that it’s YYYYMMDD, and then the 08 is probably the
milestone #. Is the 11 just the build number incremented with each
nightly build?
Question:
It sounds like the versioning is only going to happen
with major product releases (e.g. 2.0.0 will exist as a managed build revision,
and so probably will 2.0.1). Do we need to handle the case when there are
major changes milestone to milestone, etc.?
I know it’s tempting to just say “if you’re
doing development using the milestone releases, you can’t complain about
changes blowing you out of the water”, but I think there are a lot of
enthusiasts using Eclipse 3.0 and CDT 2.0 before their final releases.
Also, from a TI point of view, as we create our product, we are going to be
creating example projects to ship with our product, and this is probably going
to start prior to 2.0.1 so we will have to update our projects at some
point. It would be nice if we could easily do the updates just by loading
them into Managed Build and having it update them, rather than having to
recreate them all from scratch every time a new change to the build system
comes down the pipe during development.
Question #2:
Do we need some way of handling the ISV’s proprietary
extensions as well? I know right now it’s not exactly possible to
do this, but maybe some day Managed Build will have some extension points that
will allow vendors to add in their own custom build functionality. In
these cases it would be nice to somehow be able to specify that “my stuff
can handle vanilla CDT version X projects, but also can handle my proprietary
extensions based on X too, but can’t handle CDT version X++ projects.”
At the same time, you don’t want to eat up numbering and just change your
version to version X++ to indicate you have new capabilities beyond X but are
backwards compatible with it, as presumably there is going to be a version X++
of CDT.
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 ....
[Recoskie, Chris]
I can see it happening, but not for a good reason. I
can foresee someone in need of a clue taking CDT v. 999’s managed build plugins
and trying to ram them into their CDT 2.x install because they want the new
build capabilities and “they’re all just plugins, so it should just
work.” It’s always good to play it safe.
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.
[Recoskie, Chris]
Sounds good…
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?)
[Recoskie, Chris]
This all sounds reasonable I think.
- 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.
[Recoskie, Chris]
Always ask. They may need those projects to still work
under previous versions. Maybe they are an eager beaver and have tried
installing a new version of CDT, but their co-workers are all still using the
older version and that’s what format the projects have to stay in because
it’s project policy.
- 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).
[Recoskie, Chris]
I think so, but now we are getting into needing vendor
versioning…
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
