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

["Recoskie, Chris" <crecoskie@xxxxxx>]

 [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.

[Recoskie, Chris]

I think it’s just easier if we store a separate “Managed Build Revision” in the plugin.xml which follows the usual major.minor.service format.  That way the version of the build format can increment independently of the plug-in version, and the revisions will make a little more sense I think.  Otherwise I think it will be hard to keep the qualifiers straight.  Also, the qualifier format may change over time depending on what the build team decides to do with future projects.

 
[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.  

[Recoskie, Chris]

 

Random stream of thought follows…

 

Maybe we can just have a flag that sort of means “plus extensions”, and then the ISV supplies through the extension point mechanism a Java class that will take over.  From there the ISV can implement whatever additional versioning scheme they want (e.g. the next field they have might be their own custom revision number which they know how to interpret).

 

We probably have to devote some thought to this.  It’s not clear to me what happens when more than one plug-in wants to handle a given revision.  If you are an ISV with your own product, you probably want to take vanilla projects and convert them to your custom format, but what happens when another ISV’s stuff is in the same install and wants to do the same?  Maybe the user selects which one to use from a list?

 

And how do we specify the “brand” of extensions that have been added, so that if you try to load vendor X’s proprietary project in vendor Y’s product, you will get sensible error handling?  Maybe some sort of unique string or numeric identifier (GUID type thing) for each person that wants to create their own mutation of Managed Build?

 

Or maybe you put in the project the name of the plugin that knows how to handle you, and everyone checks this and won’t touch it if it’s non-blank but doesn’t match themselves?  That sounds more sensible.

 

Lots to think about I guess…

 [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.

 

[Recoskie, Chris]

The latter sounds better to me. That way the user doesn’t wonder why they can’t change anything (although with the greying out scheme you could always present a message too.)

 

Re: the prompting, it would be nice if they could potentially check one of those “Don’t ask me again” boxes if they like.  Of course, if we let them specify they don’t want to be asked again then I guess we need another way to initiate the conversion process or otherwise they won’t be able to do it anymore since they won’t see the dialog ever again.  Although, if they say no, and hence can’t change anything or do a build, I wonder what the benefit is of leaving it in the workspace anyway.  I guess they can still browse the code but that’s probably about it.