I have seen in version control systems the convention
major.minor.micro
but that terminology seems very technical.
"version" is neutral.
"release" has a slight taste of marketing hype in it.
"build" is used sometimes to denote micro version and gives the
impression that nothing much has changed. The project has just been built.
- rami
P T Withington wrote:
It seems that one of the most important things we could do is to come
up with less ambiguous terms than 'version' and 'release', which seem
to be used interchangeably.
'the next version of'
'the next release of'
Are there better terms?
On 2009-09-23, at 11:58, 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.
