That make me think that 'version' should be major.minor.mico, but per
your 'marketing' comment 'release' should be just 'major.minor' (or
something completely different, like how the Java 5.0 release is
version 1.5.0, or the Snow Leopard release of OS X is version 10.6.1
build 10B504). I guess that means we need a release-name theme and
generator... :)
On 2009-09-23, at 13:42, Rami Ojares / AMG Oy wrote:
major = not forward or backward compatible i.e. api was changed
minor = backward compatible but not forward compatible i.e. stuff
was added to api
micro = forward and backward compatible i.e. no changes to api, only
bug fixes, additions to docs etc.
Rami Ojares / AMG Oy wrote:
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.
