Esteemed Colleagues,
With the 0.6.4 around the corner, I'd like to propose a small extension of the
release tag/post-fixes branch scheme that has worked well for a couple of minor
versions:
Basically, the flow is this:
1) Developers and Testers work on TRUNK (testers at this point being defined as
'users feeding off trunk')
2) Developers and Testers identify suitable release candidate revisions, from
the repository history.
3) This revision is branched off as a 'release candidate' ("-rc1"), and the
version number is upped and committed only to this branch.
4) Testers now switch their focus to running the rc until they can give
feedback "rc sux" or "rc rox". Key issues:
* Has all version numbers been updated
* Does it play well with last version? Do we need to up the interface version
as well?
* Does it feel better or worse than last version?
* Any critical errors that needs fixing first?
5) If testers agree that "rc sux" the project goes back to 1) wait and look for
the next rc (rc2 et c)
6) If testers agree that "rc rox" the current rc revision is tagged as
"-release".
7) The "-release" tag is branched to a "-post-fixes" branch for continued
service awaiting the next cycle.
8) The version number (and optionally interface version) uppage is merged back
into trunk. (this is a minor merge which will probably always succeed without
conflict)
9) The project goes back to 1)
The output of this would be named revisions for each of these user categories:
== Developers ==
Feed off TRUNK, or off -rc or -post-fixes if they want some stability while
hunting bugs or doing protoyping.
== Testers ==
Feed off TRUNK or -rc depending on whether there is an RC pending release or
not. (ie, is the latest version an RC, use that, if not, use TRUNK)
== Grid/Region owners ==
Feed off "-post-fixes" if they want stability first, or off "-release" if they
want a known 'upgrade track'.
I here choose to define region owners feeding off TRUNK as 'testers'.
If I get no strong objections by monday 16th of March, I will update the
versions and download pages to reflect this process.
I'm already on 4) as I just branched off /branches/0.6.4-rc1, so testers,
please give it a spin.
It is my belief that this process would work well with how I understand the
community is using the code, with a minimum of fuss. Please note that there is
no real 'hardening' of release candidates, it's all based on back-tagging.
Best regards,
Stefan Andersson
Tribal Media AB
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
