RE: [cdt-dev] Managed Build System Versioning Strategy

[Sean Evoy <sevoy@xxxxxxxxxx>]

Thanks Chris,
I will seeyour interspersing and raise
you one....

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

"Recoskie, Chris" <crecoskie@xxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

04/16/2004 09:44 AM

Please respond to
cdt-dev

To	<cdt-dev@xxxxxxxxxxx>
cc
Subject	RE: [cdt-dev] Managed Build System Versioning Strategy

Comments interspersed…
 
___________________________________________
 
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
 
 
-----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?
[Sean Evoy]
The qualifier in the managed
build plugin's version is added automagically by the 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.

[Sean Evoy]
That's a good point. As you
say, the managed build manager could save the qualifier in the project
file and keep a list of qualifiers it cares about (i.e. a project created
in M7 now has to be upgraded to M8 format by replacing all the list options
with a ....). I was just worried about having to keep up with the nightly
qualifier, but making it an optional test should make it easier to maintain.
 
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.

[Sean Evoy]
Hmm. That is a point I had
not thought of. It seems as though toolchain and project file reading is
something that the managed build manager should be able to delegate to
ISV-supplied readers. As long as they create valid build information that
can be used to generate makefiles and display in the UI, then the logic
of handling vanilla stuff can be left to the default implementation, and
ISVs can add their own versioning and special-case handling logic in their
custom readers.  

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.
[Sean Evoy]
If the build manager decides
it should update a project and the user says no, the project will still
be in the worspace (obviously) but the user will not be able to see the
build settings from the properties page. I can think of a couple of things
we could do to minimize the frustration. One option might be to display
all of the settings but have everything greyed out/read-only. Another option
might be to replace the usual widgets with a message explaining that the
project file is old and needs updating before the settings can be viewed.
This makes me think that even if the user says no to an upgrade, the managed
build manager will keep promptingeach time a project is read in, unless
it remembers the user "preference". As well, the user may change
their minds at some later time and want the option to upgrade, even if
they have previously said no.

• 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