I have just recently released Workflow release 1.33.
I wanted to refer to a blog entry on the developer releases/branching strategy I have been using for the Worflow project, but I could not dig it up – then I found it in my blog backlog, dated 20.09.2009
So here goes,
The releases 1.33_4 and 1.33_5, both where released on the same day since they do not contain the same. Let me describe the strategy I am currently using.
The developer releases on CPAN, releases using the following format:
<major>.<minor>_<developer release>
These release are preliminary releases before a stable release. Lots of CPAN authors/contributors use this scheme and it is supported by CPAN. Many developer releases are however quite useful, at least this is my experience as a CPAN user. Workflows developer releases are however more like a snapshot, reflecting concluded work on a specific branch. They are therefor not recommended for use, unless they address a specific bug you have reported or patch you have sent.
To demonstrate. The last stable release was 1.32. Meaning that the next planned release is 1.33.
Since the release of 1.32, the following releases has been made:
- 1.33_1, patch from Andrew O’Brien, dynamic loading of config files
- 1.33_2, new tests forgotten in distribution, my bad
- 1.33_3, bug fix based on report from Sergei Vyshenski
- 1.33_4, patch from Danny Sadinoff finer grained control of initialization
- 1.33_5, patch from Thomas Erskine, new accessors and a bug fix
- 1.33_6, patches from Alejandro Imass
- 1.33_7, patch from Ivan Paponov
- 1.33_8, accumulated release and 1.33 release candidate
All are based on branches and the releases are made from the relevant branch before merging into trunk. The actual merge will not be made until the preparation of the 1.33 release begins.
All branches are based on release 1.32 so the different releases do not contain each other. The reason for this is:
- The releases are made to indicate concluded work on a branch and evaluation can begin by patchers/reporters and other interested parties, as I mentioned earlier
- A release made to CPAN gets thrown at the CPAN-testers, so the release can be smoked
- A branch might be discarded if agreed upon by involved parties
In regard to the above development releases, a merged release should probably be made in order to get the 1.33 release candidate tested.
I am not sure what strategy is made by other CPAN authors/contributors, so feedback is very much welcome, since I am not aware of what the best practice is or the de facto use of the developer release scheme.
0 Comments.