[fdo-internals] Creation of FDO 3.3 revision branches tosupportAutodesk hotfixes

[Jason Birch]

Welcome Dave; good to meet you.

Sorry to take so long to follow up; been helping to run a local government IT conference this week and been swamped.  Might be affecting my current tone somewhat; sorry if so. ;)

I think that we had a discussion about branching and tagging strategies earlier this year with the current single-branch, multiple tags system for point releases as a result.  If I understand this correctly, the current system of creating tags on the supposed-to-be stable point releases is not adequate for Autodesk's internal release process for new builds of FDO. Is the concern here that substantial changes may be made in the (for instance) 3.3 branch between point releases that you may not want to deliver in hotfixes; that the 3.3 branch may not be stable enough or may include features rather than just bug fixes to the extent that you wouldn't just want to tag the point-level branch?  Or do you need more flexibility on which of the bug fixes you choose to apply as hot fixes because of limited testing resources?  As I said, I don't have a problem with this if it's necessary for your internal business needs.  I think this is pretty uncommon in the open source world though; generally releases are built against the stable branch rather than a point release of the stable branch.
 
Incidentally, I have absolutely no problem with Autodesk's requirements driving the release schedule for new versions of FDO at this point and, as you suggest, being open to intermediate community releases as desired.  The majority of the development work is still being done by Autodesk, and this strategy makes a lot of sense as long as this is the case.  It would be useful to have some idea of this schedule in advance though, with clear communication of these needs so that the open source developers such as Haris, Mateusz, and Bruno who are maintaining providers would have a better idea of whether they have the resources to ensure that their providers are up to date before the release process starts.  I know that it is difficult to acomplish this, especially with the complexity of multiple locations for issue tracking and release schedules, but it would be very useful as long as we are relying on Autodesk's generosity for new release packages.
 
Wandering off the original topic a bit, but also along these lines... I'd like to see some more buy-in on the cmake build system that Helio built and provided.  Has anyone had a chance to look at his patches?  Would it be acceptable to integrate his system into the source tree and maintain it as a parallel build system?  I'm hoping to find time to work on an open source build and package process for MapGuide in the next while, and I'm thinking that having this system in place for FDO may make my life easier.
 
Jason

________________________________

From: fdo-internals-bounces at lists.osgeo.org on behalf of Robert Fortin
Subject: RE: [fdo-internals] Creation of FDO 3.3 revision branches tosupportAutodesk hotfixes



Jason,

 

Let me introduce Dave.  Dave Wilbur is working with a customer support group within Autodesk and he and his team are looking into making hotfixes available to our customers the most efficient way.  We are also concerned that we want these modifications to benefit the entire community and, as you clearly pointed out, show open-ness.  

 

The intent was not to impose Autodesk schedule on the community and maybe the way it was presented lead you to think that it was the case.  But instead, it was trying to communicate our intent with regards to our current and upcoming releases.  Dave also suggesting interesting changes that will help better track the version and build of FDO.  We actually suggested that this be communicated to the community exactly to show open-ness.

 

As a matter of fact, FDO version 3.3.1 has been released to the community but no branch created for it.  Further work was done in the interest of MG OS and it is done with the intent that this would become 3.3.2.   The intent of publishing this version under 3.3.2 is what is proposed by Dave in order to have a recognizable point release for MG OS community. 

 

As for the hotfix strategy, it is not different than what FDO has been following so far.  Creating 3.X.X branch to hold hotfixes have been done in the past.  It just has the chance of happening more often going forward.  All Dave is proposing is to have new branches that will allow the community (and of course Autodesk! :^) ) to make small modification over a specific release.  That's good news!

 

I think the community and the FDO PSC is solely responsible for deciding when to create a point release.  As always, Autodesk will suggest when this should happen and the PSC will decide. 

 

The proposal at this point is to publish the build of branches/3.3 (rev 4505) as release 3.3.2 and create branches for 3.3.1 and 3.3.2 (which doesn't exist at the moment). 

Does the PSC and the FDO communicaty have any objection against it?

 

Robert Fortin

 

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Thursday, September 25, 2008 5:29 PM
To: FDO Internals Mail List; fdo-internals at lists.osgeo.org
Subject: RE: [fdo-internals] Creation of FDO 3.3 revision branches to supportAutodesk hotfixes

 

David, I have no problem with the technical suggestion of branches to support hotfixes on point releases, and agree that physical file versions should match the release number.  However, I think that there is a disconnect here in the amount of communication between Autodesk and the community on releases.  Is there no opportunity to change procedures so that rather than Autodesk product-specific releases and community releases, there are just releases?

 

In general I think there needs to be a bit more open-ness, at least as much as is permitted from a publicly traded company.  I understand that it is hard to live within two communities--one completely closed and the other entirely public--but there is certainly some room for improvement.  It would be helpful if more of the people who are involved with FDO within Autodesk took a more active role in the community, or at least stopped by and introduced themselves :)

 

Jason

 

________________________________

From: fdo-internals-bounces at lists.osgeo.org on behalf of David Wilbur
Sent: Thu 2008-09-25 1:25 PM
To: fdo-internals at lists.osgeo.org
Subject: [fdo-internals] Creation of FDO 3.3 revision branches to supportAutodesk hotfixes

Hello FDO community,

 

In an effort to support hotfix revisions for versions of FDO released by Autodesk, we will need to create point revision branches in the SVN vault to match any Autodesk releases. Any hotfix updates for a release will then be submitted to these new branches.

 

Here is a list of proposed new branches and the corresponding Autodesk releases:

 

fdo/branches/3.3.1    AutoCAD Map 3D, MapGuide, and Topobase 2009  (from SVN revision 3791/3802)

fdo/branches/3.3.2    Update 1 for AutoCAD Map 3D, MapGuide, Topobase 2009 and SQL Server Spatial (from SVN revision 4045)

 

By creating SVN branches for every Autodesk release we can ensure that hotfixes can always be created for each release.

 

Note that this strategy does not preclude the creation and release of any interim build revisions that do not correspond to Autodesk releases. If a release is created without a corresponding Autodesk release, we will just increment to the next revision for the next Autodesk release.

 

On a related topic, we are planning to implement a file versioning scheme to follow this release format. Currently, all Autodesk releases have been distributed with file versions of 3.0.0.x, when they really should have been numbered according to the corresponding revision.

 

Once we adopt this strategy, the next Autodesk release can start using the proper file numbering. Eg. For Map 3D 2009 Update 2 the files will potentially be versioned 3.3.3.x.

 

To simplify the migration of the FDO build to new version numbers, I would also like to propose that the FDO vcproj files be changed to use a parameterized input for the version number. The first 3 digits are currently hard coded in the FDO vcproj file post build steps. A simplified version configuration could be accomplished by either using a new build environment variable, changing the post build steps to read the version number from a vault file, or by using a 'resource file include' scheme where the version rc resource information is stored in a common shared header file.

 

Please respond soon with your thoughts on these topics, as we need to move forward quickly with a solution for the building of hotfixes for FDO.

 

Thank you,

 

Dave

 

cid:image001.gif at 01C63097.C5E10050
David Wilbur
Software Developer
Geospatial Business Unit - Customer Response Team

Direct       618 345-0989