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?