[mapguide-internals] RE: File versions...

[Trevor Wekel]

I'm ok with the modulus.  Assuming the build number is int16 then and we have 2000 changes a year it will be 2025 by the time the build number wraps.


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Friday, March 13, 2009 6:54 PM
To: mapguide-internals at lists.osgeo.org
Subject: Re: [mapguide-internals] RE: File versions...

I'm not sure I like the idea of checking in changes to files for passive acts like building.

Couple other ideas...

You could wrap the revision number ( revision % maxint ).  This would cause a problem with non-sequential numbers for one point release, so we would have to auto-increment one point release every 65k revisions which I'd guess is about once per decade if we're lucky :)

Or, instead of revving the checked-in build number on each build, we could store the base revision number every time we cut a new release.  This would be subtracted from the current revision number to give that build's build number.  For example:

- the value 3041 is stored in /trunk/baseversion.txt
- trunk builds (destined for 2.1) use currentrev - baseversion for their build number: 2.1.0.0, 2.1.0.14, ...
- 2.1 is branched, trunk baseversion.txt is updated to 3752 (guess)
- trunk builds (destined for 2.2) use  currentrev - baseversion for their build number: 2.2.0.9, 2.1.0.18, ...

Nice thing about this is that the base version comes along for the ride with branching.

Jason

 

----- Original Message -----
From: mapguide-internals-bounces at lists.osgeo.org <mapguide-internals-bounces at lists.osgeo.org>
To: MapGuide Internals Mail List <mapguide-internals at lists.osgeo.org>
Sent: Fri Mar 13 16:20:41 2009
Subject: [mapguide-internals] RE: File versions...

The SVN revision number does not depend on the release.  Changeset 3735 is the number of changes since we created the vault.  For example, MapGuide 1.0.0 is revision 696.  MapGuide 2.0.0 is revision 3041.  Assuming MapGuide sticks around for a few years, we will eventually  hit 65k revisions.


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Walt Welton-Lair
Sent: Friday, March 13, 2009 4:03 PM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RE: File versions...

Do you think we'll ever have > 65000 revisions in one release cycle?  Not being a pessimist, just a realist :-).

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Friday, March 13, 2009 5:57 PM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RE: File versions...

I need to start looking at build automation again.  It should be possible to increment the file versions with every build.  We could start at build 1 for each new release and increment the "build number" before each build is performed. The build number would be stored as a file in subversion.

I liked the SVN revision idea but what happens when we hit 65,000 revisions?


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Walt Welton-Lair
Sent: Friday, March 13, 2009 3:32 PM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RE: File versions...

I think it would be worthwhile to update the major & minor values each release.

There's a freeware tool called StampVer (http://www.elphin.com/products/stampver.html) which can be used to set version information in DLLs / EXEs.  But it doesn't work on 64-bit modules.

Walt


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Friday, March 13, 2009 4:59 PM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] File versions...

Hi all,

Looking at the code, the .rc files generally do not reflect the current MapGuide version number.

Is it worth maintaining these manually to keep in sync with at least the current release major version?

Is there a utility that can be run post-build to update the file versions embedded in .dlls (and exes?) to reflect something like the MapGuide version number + SVN revision? (2.1.0.3728)

Jason
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals