Question to the community: preferred release process
sventon project
Currently our release process for sventon look like this:
1) develop new features in "trunk"
2) prepare for a release by creating a maintenance branch for eg. version 2.0
3) release a RC (release candidate) eg. 2.0 RC1
4) fix reported bugs in the maintenance branch (and merging them to trunk)
5) repeat step 3 and 4 until the version seem stable
6) release a final version eg. 2.0.0
This process clearly prioritizes stability over new features, with the
drawback that a feature can be implemented in trunk, but not included
in a release until a couple om months later.
Our question to the community is if we should change this.
In that case, an alternative process could look like this:
1) develop new features in "trunk"
2) create a release directly from trunk, eg. 2.1
3) fix reported bugs in trunk
4) repeat all steps
5) keep major redesign/refactorings in a working branch merging to
trunk when ready
This would make new features available faster to those of you not keen
on building your own releases. The downside is that less testing as
betas or release candidates can potentially bring somewhat less stable
releases.
What do you prefer?
--sventon team
Dirk Olmes
> Hi!
>
> Currently our release process for sventon look like this:
>
> 1) develop new features in "trunk"
> 2) prepare for a release by creating a maintenance branch for eg. version 2.0
> 3) release a RC (release candidate) eg. 2.0 RC1
> 4) fix reported bugs in the maintenance branch (and merging them to trunk)
> 5) repeat step 3 and 4 until the version seem stable
> 6) release a final version eg. 2.0.0
>
> This process clearly prioritizes stability over new features, with the
> drawback that a feature can be implemented in trunk, but not included
> in a release until a couple om months later.
For Mule we use a model simliar to this one but that doesn't necessarily
mean that new features won't make it in earlier. We develop features on
feature branches that we branch off of trunk and use svnmerge to
re-integrate from the feature branch to trunk or the release branch when
the feature is ready.
It's a bit more maintainance work but works nicely.
-dirk
Stephen Connolly
1. Develop new features in trunk
2. Release often
3. Very big changes are developed in a branch and merged back to trunk.
Most people seem fine with the once a week or more often if there are issues release pace of Hudson....
Though it can be fun deciding when to update, and how far to update!
-Stephen