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
<[email protected]> 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: [email protected]
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.
