I'd like to simplify our process for creating (what we call) 'point
release's, releases where we are incrementing the 3rd component of the
release ID, which typically only include a very small number of
targeted fixes in response to customer or maintenance contracts.
Since these point releases are typically only targeted to a single
customer, I don't feel we should have to go through the full [Release
Process](http://wiki.openlaszlo.org/Release_Process).
What I'd like to propose is that we separate out the concept of a
"version" and a "release". Taking the current 4.6.2 branch as an
example, I propose that it would be known as Version 4.6, Release 2.
I propose that we would implement this new procedure in trunk and put
it into effect in Version 4.7. Basically, rather than
build.properties having version.id and release.id which are redundant,
we would have version.id be the first two components of the current
version (e.g., 4.7) and release.id would be 0, and incremented for
each point release (should there be any) out of that branch.
A goal of this simplification is to reduce the overhead of a point
release, so that there is no need to update release notes or web
content to create the point release. The point release can simply
replace the previous point release on the download server.
The major work that would be needed to do this:
. Adjust the build system to know the difference between version and
release, using the appropriate combination in each place. In
particular, this should remove the requirement that the nightly-build
script has to be updated for each point release, and remove the point
designation from the download paths and images (so the download page
will not need to be updated).
. Adjust any parameterized documentation to know the difference
between @VERSIONID@ and @RELEASEID@, using the appropriate combination
in each place. This should remove the need to update the release
notes for point releases.
. Adjust the LFC and debugger to know the difference between version
and release, using the appropriate combination in each place. This
should simply be a reorganization of the canvas attributes and the way
the debugger prints version and release info for bug reports, etc.
