Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Stuart Donaldson <stu@as...> - 2003-02-11 05:42:06
In preparing the 0.8 release, rolling the version numbers in the release
was one of the painful parts, because of all the places that they occur.
I created a script to do this, but it was fairly specific. It would be
nice to have a more general solution.
One suggestion is to tag the version number and release date. In the
HTML files we could tag them with a HTML comments delimiting them. Then
a script could go through and perform the requisite substitutions.
Something like: <!-- version --> 0.8 <!-- /version -->
and <!-- releaseDate --> February 9, 2003 <!-- /version -->
This could be automagically fixed up by a script prior to doing a release.
Another issue is the RelNotes-0.*.html files. Should we start
collecting the Release Notes in a new file now? Or wait until prior to
the next release and scan the CVS logs? If we create the file now, we
don't know what the next version will be. Could be 0.9, 0.8.1 or
something else. So creating a named version for it now doesn't make a
lot of sense.
We could roll the version in CVS to 0.8.X and then create a
RelNotes-0.8.X.html files, renaming them once we get ready for another
release. The advantage to this would be that it allows us to continue
with the Release notes files, and the install.py script that builds the
documentation indexes would also continue to reference the new files.
If this is a good idea, maybe we should just roll it to 0.X.Y so that
we can always use 0.X.Y between releases, and then rename the version to
the next number.