Item1183: Revision shouldn't be built from some subversion auto-replacement mechanism

Most of the time we're using $Rev$ to build out a version number for extensions, or even for the core.

It's not really smart, as it doesn't really reflect the latest time the entire extension has been updated, nor the current state of the tree of the developer who's uploading it.

Therefore, it should be smarter to use some manually defined mechanism, and integrate that into BuildContrib.

The fact that this will help us migrate out of Subversion is accessory and not what motivates this task, as some other SCM (such as Mercurial) have this keyword replacement feature built it.

I think what we need first is a list of functionalities we would like this module to have. I'd say:

• Ability to manually select a version number for an extension, and foswiki
• Replacement is done only when building something, therefore it's integrated in BuildContrib
• Ability to retrieve the last version number (if it's a plugin, get it from its page on Foswiki.org, if it's Foswiki.org, hum... find a way :))

Like that, we will never again have to worry about setting svn properties (keywords replacement) on the server, and on the clients (never knew where it should be done), for existing and new extensions.

And an added gain is that scripts won't depend of having a Subversion checkout, thus one can use his favorite SCM, and still upload extensions.

-- OlivierRaginel - 02 Mar 2009

I agree.

Infact, all of the plugins I maintain have already a manual version information for the reason outlined above, that is I don't use an auto-generated tag in the plugin info table. Instead I am setting it manually before uploading to foswiki.org. This is then reflecting the normal major.minor.patch.extra pattern that are used elsewhere for obvious purposes.

-- MichaelDaum - 02 Mar 2009

I also agree. However I do not want to maintain version numbers manually when subversion does the same thing automatically. I did actually write this into BuildContrib (check the MANIFEST, get the latest rev of all files) at one point. Can't remember what happened to it.

Note that we have $RELEASE for the manual version identifier. That's what it's for. Unfortunately even this simple mechanism has defeated some people.

-- CrawfordCurrie - 02 Mar 2009

i think it is highly desirable to push this functionality out of subversion and into the build tools. although i am not using git currently, i would like to someday. and today, i routinely use svk for all my development.

-- WillNorris - 30 Mar 2009

Thanks to Item1375, BuildContrib now supports git anyway, at least git-svn for now, so you may use it at will

-- OlivierRaginel - 30 Mar 2009

I added the RELEASE identifier to support this. Also added the new 'tracked' target to further refine on versioning. $VERSION is still the SVN rev, it's just not used the same way.

-- CrawfordCurrie - 29 Jul 2009

Fixed the build.pl script of the core so it can be built (it pointed to Build.pm as rootModule, as this doesn't exist, I have it point to Foswiki.pm).

-- OlivierRaginel - 04 Aug 2009