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

[Rami Ojares / AMG Oy]

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