[Laszlo-dev] Simplifying our 'point release' process

[Rami Ojares / AMG Oy]

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.
>>
>>
>