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

[Amy Muntz]

As part of the process, we've taken a pass a making JIRA simpler too. 
Now, when you file a bu in JIRA, you won't have a zillion options to 
choose from for the Affects, Fix For versions. JIRA will display the 
most recent supported releases in all the branches.


On Thu, Sep 24, 2009 at 12:15 PM , P T Withington wrote:

> This is a good point.  I guess I was seeing them as coupled because of 
> the work I have to do for each release just to make the build have the 
> right version number.
>
> So, instead of what I proposed, I am going to see if I can simplify 
> the work to updating a single file that specifies the mapping:
>
>   branch-name, svn revision -> 'marketing/pretty' version number
>
> If I can make the nightly build script and the ant build system be 
> driven off a single table like this, then it will seem a lot easier to 
> create a point release.
>
> I also think that given that table, I should be able to write a script 
> that will compute the bug fixes in the point release and insert them 
> into the release notes.  (This will depend on developers _accurately_ 
> recording the bug that each svn change is fixing.  So, for a major 
> release, we'll want to go over the output of any such tool manually; 
> but for a minor release the automated output should be close enough. 
> Anyone who has to know if a particular bug is fixed in a release can 
> determine that by comparing the Jira fix version with the versions 
> that are included in the branch.)
>
> Finally, we're just not going to bother going through the whole 
> deploy/update/announce overhead for point releases that we suspect 
> will be immediately obsolete.  If we have one that we know will have a 
> lifetime of more than a few weeks, we will push it out to the 
> community as a general improvement.
>
> On 2009-09-23, at 21:24, Sarah Allen wrote:
>
>> 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 
>> <mkolenda at laszlosystems.com> 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: mkolenda at laszlosystems.com
>>>
>>>
>>> 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.