Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi
I meant just tag names, to conform PEAR. The structure is up to us.
Well I'd anyway prefer using something else what support branches
better than CVS as CVS sucks in this field, especially in merging
changes across branches.
I'd suggest to use following:
HEAD
- QA_2_7_0 (branch)
- RELEASE_2_7_0 (tag)
- MAINT_2_7_0 (optional, branch point is RELEASE_2_7_0)
- RELEASE_2_7_0_1 (former 2.7.0-pl1)
- RELEASE_2_7_0_2 (former 2.7.0-pl2)
- RELEASE_2_7_1 (tag)
- MAINT_2_7_1 (optional, branch point is RELEASE_2_7_1)
- QA_2_8_0 (branch)
- RELEASE_2_8_0 (tag)
- MAINT_2_8_0 (optional, branch point is RELEASE_2_8_0)
- RELEASE_2_8_1 (tag)
- MAINT_2_8_1 (optional, branch point is RELEASE_2_8_1)
And so on.
- QA_2_8 (branch, created from HEAD when 2.8 is feature frozen)
- RELEASE_2_8_0RC1 (tag) phpMyAdmin-2.8.0rc1
- RELEASE_2_8_0 (tag) phpMyAdmin-2.8.0
- RELEASE_2_8_0_1 (tag) phpMyAdmin-2.8.0.1 (was pl1)
- RELEASE_2_8_0_2 (tag) phpMyAdmin-2.8.0.2 (was pl2)
- RELEASE_2_8_1RC1 (tag) phpMyAdmin-2.8.1rc1 (no new features in the
2.8 branch)
- RELEASE_2_8_1 (tag) phpMyAdmin-2.8.1
- QA_2_9 (branch, created from HEAD when 2.9 is feature frozen)
- RELEASE_2_9_0 (tag)
- RELEASE_2_9_0_1 (tag)
- RELEASE_2_9_1 (tag)
I don't see the need for MAINT structure.
Branch/Tag names match with file names.
- QA_2_8 (branch, created from HEAD when 2.8 is feature frozen)
- RELEASE_2_8_0RC1 (tag) phpMyAdmin-2.8.0rc1
- RELEASE_2_8_0 (tag) phpMyAdmin-2.8.0
- RELEASE_2_8_1 (tag) phpMyAdmin-2.8.1 (was pl1)
- RELEASE_2_8_2 (tag) phpMyAdmin-2.8.2 (was pl2)
- RELEASE_2_8_3RC1 (tag) phpMyAdmin-2.8.3rc1 (no new features in the
2.8 branch)
- RELEASE_2_8_3 (tag) phpMyAdmin-2.8.3
release candidates for bugfix releases?
Yes, because a bugfix release (2.8.x) needs testing also. But you are
the one who suggested a fourth number for the patch level, now you no
longer want a fourth number?
only if required, as described below
as i wrote, i dont see big difference between normal bugfixes and
security bugfixes
2_8_0_1 is only required if there are more changes in the 2_8 BRANCH
after 2_8_0 RELEASE what should not go into this release (f.e. needs
more testing)
but i don't think that this will happen much often, if a bugfix is
really such bug that it need heavy testing it should go into next 2_X (HEAD)
because than it is like a new feature, it is possible that this also
changes things not wanted/expected by the user in a bugfix only release
i don't
think that its a big different between normal bug fix releases
and security fix releases - and the need for RC is equal in booth cases
MAINT_X_X_X can be created as required
for example, a big bugfix merged into QA_2_8 needs more testing
but a security fix needs immediate release
That's why I suggest a 2.8.1RC1.
create MAINT_2_8_0 from release tag RELEASE_2_8_0
and merge the security fix and release 2.8.0.1
but only if current QA_2_8 is not ready for release
I got your point. But this could be called also QA_2_8_0.
but this follows not the PEAR cvs standard as i read it ... or?
--
Sebastian Mendel
www.sebastianmendel.de
www.sf.net/projects/phpdatetime |
www.sf.net/projects/phptimesheet