I don't understand why the release process and the numbering scheme
are coupled. I think certain people will expect release notes or
whatever no matter what the build is called. I would focus in process
(or your desire for a lack thereof) rather than than the number scheme.
My $.02
Sent from my iPhone
On Sep 23, 2009, at 9:42 AM, Matt Kolenda <[email protected]>
wrote:
Tucker
May I suggest that the Release ID begin at 1 instead of 0. People
tend to refer to releases as ordinal numbers starting at 1.
Matt
Matt Kolenda
Laszlo Systems
mobile: 415.505.5393
email: [email protected]
On Wed, Sep 23, 2009 at 8:58 AM , P T Withington wrote:
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.
