Hi,
I suggest 2.7.1-rc1 (or beta) on Jan 29th. I don't think we can "deglobalize" for 2.7.1, but we should be aiming to test/stabilize the tree before any bigger change.
I would like to fix those bugs before:
- 1376314: in some cases, SHOW GRANTS does not return the db-specific privileges
- 1396998: exact row count for VIEWs
Anything else you feel is urgent?
Marc
Hi
On Tue, 17 Jan 2006 08:21:08 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I suggest 2.7.1-rc1 (or beta) on Jan 29th. I don't think we can "deglobalize" for 2.7.1, but we should be aiming to test/stabilize the tree before any bigger change.
I agree ... Anyway I will be offline in week starting from this date.
Marc Delisle schrieb:
Hi,
I suggest 2.7.1-rc1 (or beta) on Jan 29th. I don't think we can "deglobalize" for 2.7.1, but we should be aiming to test/stabilize the tree before any bigger change.
I would like to fix those bugs before:
- 1376314: in some cases, SHOW GRANTS does not return the db-specific
privileges
- 1396998: exact row count for VIEWs
Anything else you feel is urgent?
no
and after this, can we split CVS into 2.8 and 2.7?
making it easier/faster to release bug fix releases for 2.7
and add new features only to 2.8 ?
... i know it makes more trouble merging patches in two branches, but the advantage is we can more often release bug fix releases
... and renaming x.x.x-pl1 into x.x.x.1 if this is still needed as we have two branches (new feature branch (2.8) and bugfix branch (2.7))
... so bugfix releases (current x.x.x-plx) will also have other bugfixes than only security fixes
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Hi,
I suggest 2.7.1-rc1 (or beta) on Jan 29th. I don't think we can "deglobalize" for 2.7.1, but we should be aiming to test/stabilize the tree before any bigger change.
I would like to fix those bugs before:
- 1376314: in some cases, SHOW GRANTS does not return the db-specific
privileges
- 1396998: exact row count for VIEWs
Anything else you feel is urgent?
no
and after this, can we split CVS into 2.8 and 2.7?
making it easier/faster to release bug fix releases for 2.7
and add new features only to 2.8 ?
... i know it makes more trouble merging patches in two branches, but the advantage is we can more often release bug fix releases
... and renaming x.x.x-pl1 into x.x.x.1 if this is still needed as we have two branches (new feature branch (2.8) and bugfix branch (2.7))
... so bugfix releases (current x.x.x-plx) will also have other bugfixes than only security fixes
Ok for me.
Marc
Hi
On Fri, 20 Jan 2006 10:26:14 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
Marc Delisle schrieb:
Hi,
I suggest 2.7.1-rc1 (or beta) on Jan 29th. I don't think we can "deglobalize" for 2.7.1, but we should be aiming to test/stabilize the tree before any bigger change.
I would like to fix those bugs before:
- 1376314: in some cases, SHOW GRANTS does not return the db-specific
privileges
- 1396998: exact row count for VIEWs
Anything else you feel is urgent?
no
and after this, can we split CVS into 2.8 and 2.7?
Next release will be 2.8 or all upcoming 2.7 releases will be bugfix only? I'd prefer staying with current practice - create branch for release and develop in HEAD. Which will later become release.
Michal Čihař schrieb:
Hi
On Fri, 20 Jan 2006 10:26:14 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
Marc Delisle schrieb:
Hi,
I suggest 2.7.1-rc1 (or beta) on Jan 29th. I don't think we can "deglobalize" for 2.7.1, but we should be aiming to test/stabilize the tree before any bigger change.
I would like to fix those bugs before:
- 1376314: in some cases, SHOW GRANTS does not return the db-specific
privileges
- 1396998: exact row count for VIEWs
Anything else you feel is urgent?
no
and after this, can we split CVS into 2.8 and 2.7?
Next release will be 2.8 or all upcoming 2.7 releases will be bugfix only? I'd prefer staying with current practice - create branch for release and develop in HEAD. Which will later become release.
yes, create branch '2.7' and add only bugfixes there
and new feature goes to HEAD what will become later 2.8
Michal Čihař a écrit :
Hi
On Fri, 20 Jan 2006 10:26:14 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
Marc Delisle schrieb:
Hi,
I suggest 2.7.1-rc1 (or beta) on Jan 29th. I don't think we can "deglobalize" for 2.7.1, but we should be aiming to test/stabilize the tree before any bigger change.
I would like to fix those bugs before:
- 1376314: in some cases, SHOW GRANTS does not return the db-specific
privileges
- 1396998: exact row count for VIEWs
Anything else you feel is urgent?
no
and after this, can we split CVS into 2.8 and 2.7?
Next release will be 2.8 or all upcoming 2.7 releases will be bugfix only? I'd prefer staying with current practice - create branch for release and develop in HEAD. Which will later become release.
I think Sebastian's idea is to say that release 2.8.1 does not have more features than 2.8.0, only bugfixes. Critical bugfixes can still be named with -plX.
Marc
Hi
On Fri, 20 Jan 2006 08:15:12 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I think Sebastian's idea is to say that release 2.8.1 does not have more features than 2.8.0, only bugfixes. Critical bugfixes can still be named with -plX.
Okay, this sounds reasonable for me. But maybe then we could abandon those -plX as it just complicates versioning scheme.
Michal Čihař a écrit :
Hi
On Fri, 20 Jan 2006 08:15:12 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I think Sebastian's idea is to say that release 2.8.1 does not have more features than 2.8.0, only bugfixes. Critical bugfixes can still be named with -plX.
Okay, this sounds reasonable for me. But maybe then we could abandon those -plX as it just complicates versioning scheme.
So it's time to clarify the branch names.
HEAD would contain the new features + obviously all the bug fixes.
RELEASE_2_8_0 would contain ... 2.8.0, what a surprise!
Instead of having QA_2_8_0, we could name this branch QA_2_8. Into this one, we merge all the fixes that apply to the 2.8 series. When we feel it's ready, we release 2.8.1-rc1 from it (or directly 2.8.1 ?)
My only question is: what happens if we need to release something quickly? I guess we could start from QA_2_8 but then it would contain all the accumulated fixes for this branch. This is a case where a 2.8.0-pl1 (a quick patch applied to RELEASE_2_8_0) would be handy.
Marc
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi
On Fri, 20 Jan 2006 08:15:12 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I think Sebastian's idea is to say that release 2.8.1 does not have more features than 2.8.0, only bugfixes. Critical bugfixes can still be named with -plX.
Okay, this sounds reasonable for me. But maybe then we could abandon those -plX as it just complicates versioning scheme.
So it's time to clarify the branch names.
HEAD would contain the new features + obviously all the bug fixes.
RELEASE_2_8_0 would contain ... 2.8.0, what a surprise!
Instead of having QA_2_8_0, we could name this branch QA_2_8. Into this one, we merge all the fixes that apply to the 2.8 series. When we feel it's ready, we release 2.8.1-rc1 from it (or directly 2.8.1 ?)
My only question is: what happens if we need to release something quickly? I guess we could start from QA_2_8 but then it would contain all the accumulated fixes for this branch. This is a case where a 2.8.0-pl1 (a quick patch applied to RELEASE_2_8_0) would be handy.
like here:
http://www.akhphd.au.dk/~bertho/cvsgraph/ http://cvs.m17n.org/~akr/cvstree/ http://www.cvs-ext.com/graph.gif
Hi
On Tue, 24 Jan 2006 07:41:48 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
like here:
http://www.akhphd.au.dk/~bertho/cvsgraph/ http://cvs.m17n.org/~akr/cvstree/ http://www.cvs-ext.com/graph.gif
Better like here:
http://pear.php.net/manual/en/standards.cvs.php
Michal Čihař schrieb:
Hi
On Tue, 24 Jan 2006 07:41:48 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
like here:
http://www.akhphd.au.dk/~bertho/cvsgraph/ http://cvs.m17n.org/~akr/cvstree/ http://www.cvs-ext.com/graph.gif
Better like here:
HEAD - QA_2_7_0 - RELEASE_2_7_0 - MAINT_2_7_0 - QA_2_7_1 - RELEASE_2_7_1 - MAINT_2_7_1 - QA_2_8_0 - RELEASE_2_8_0 - MAINT_2_8_0 - QA_2_8_1 - RELEASE_2_8_1 - MAINT_2_8_1
against
HEAD - 2_7 - 2_7_0 // Release branch \ 2_7_0_0 // RC1 release tag \ 2_7_0_1 // Final release tag - 2_7_1 // bugfix branch \ 2_7_1_0 // bugfix release tag \ 2_7_1_1 // security fix release tag - 2_7_2 // bugfix branch \ 2_7_2_0 // bugfix release tag - 2_8 - 2_8_0 // Release branch \ 2_8_0_0 // RC1/Final release tag - 2_8_1 // bugfix branch \ 2_8_1_0 // bugfix release tag
???
why is this better?
Sebastian Mendel schrieb:
Michal Čihař schrieb:
Hi
On Tue, 24 Jan 2006 07:41:48 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
like here:
http://www.akhphd.au.dk/~bertho/cvsgraph/ http://cvs.m17n.org/~akr/cvstree/ http://www.cvs-ext.com/graph.gif
Better like here:
http://pragmaticprogrammer.com/titles/svn/tags_and_branches.pdf (http://pragmaticprogrammer.com/titles/svn/)
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html
http://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_...
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.
Michal Čihař schrieb:
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.
ok,
and how will RC's fit into this?
Hi
On Wed, 25 Jan 2006 10:27:43 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
and how will RC's fit into this?
Not yet ;-). Maybe RELEASE_2_7_0_RCx? We need to have known mapping of version and CVS tags so that those are unique...
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.
Marc
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?
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
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
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?
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.
Marc
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 a écrit :
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
I do. Suppose we release 2.8.0 (RELEASE_2_8_0). In my suggested scheme, we merge fixes into the QA_2_8 branch to eventually release 2.8.1. But we need to release a security fix, so we open MAINT_2_8_0 based on RELEASE_2_8_0, put the fix and release 2.8.0.1. This is different than releasing 2.8.1, in the number of fixes and in the testing delay in the field.
So we would not have QA_2_8_0, but QA_2_8.
On the other hand, 2.8.1 would have a RC because of the bigger number of fixes.
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)
Agreed, a bugfix must not be too much disrupting in the logic.
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?
Ok, so let's name this MAINT.
Marc
On Wed, 25 Jan 2006 07:34:19 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
- 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.
MAINT is needed if you need security fix for 2.8.0 but you already did some changes for 2.8.1 in QA_2_8 branch. In this case MAINT_2_8_0 will branch from RELEASE_2_8_0 and RELEASE_2_8_0_1 will be tag of it.
Michal Čihař a écrit :
On Wed, 25 Jan 2006 07:34:19 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
- 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.
MAINT is needed if you need security fix for 2.8.0 but you already did some changes for 2.8.1 in QA_2_8 branch. In this case MAINT_2_8_0 will branch from RELEASE_2_8_0 and RELEASE_2_8_0_1 will be tag of it.
I see. Agreed.
Marc
Hi
On Mon, 23 Jan 2006 19:30:16 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
HEAD would contain the new features + obviously all the bug fixes.
RELEASE_2_8_0 would contain ... 2.8.0, what a surprise!
Instead of having QA_2_8_0, we could name this branch QA_2_8. Into this one, we merge all the fixes that apply to the 2.8 series. When we feel it's ready, we release 2.8.1-rc1 from it (or directly 2.8.1 ?)
There still should stay rc because that branch will not be that much tested by developers (most of work will be done on HEAD).
My only question is: what happens if we need to release something quickly? I guess we could start from QA_2_8 but then it would contain all the accumulated fixes for this branch. This is a case where a 2.8.0-pl1 (a quick patch applied to RELEASE_2_8_0) would be handy.
You're right, we can keep this way. However I'd call such release 2.8.0.1 as this makes version comparing much easier (and sometimes version is not allowed to contain dash).
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi
On Fri, 20 Jan 2006 08:15:12 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I think Sebastian's idea is to say that release 2.8.1 does not have more features than 2.8.0, only bugfixes. Critical bugfixes can still be named with -plX.
Okay, this sounds reasonable for me. But maybe then we could abandon those -plX as it just complicates versioning scheme.
So it's time to clarify the branch names.
HEAD would contain the new features + obviously all the bug fixes.
RELEASE_2_8_0 would contain ... 2.8.0, what a surprise!
HEAD
- branch 2_8
- branch 2_8_0 // * 2006-01-23 *
release 2_8_0_0 // RC1 release 2_8_0_1 // RC2 release 2_8_0_2 // FINAL release 2_8_0_3 // very quick release (security fix, pl1)
- branch 2_8_1 normal fix reales
release 2_8_1_0 // RC1 ?? release 2_8_1_1 // FINAL release 2_8_1_2 // very quick release (security fix, pl1)
- ...
- branch 2_9 // * 2006-03-?? *
- ...
just like this one:
http://weblogs.mozillazine.org/roadmap/archives/2005_12.html
to keep it small, we have always only two branches open
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi
On Fri, 20 Jan 2006 08:15:12 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I think Sebastian's idea is to say that release 2.8.1 does not have more features than 2.8.0, only bugfixes. Critical bugfixes can still be named with -plX.
Okay, this sounds reasonable for me. But maybe then we could abandon those -plX as it just complicates versioning scheme.
So it's time to clarify the branch names.
HEAD would contain the new features + obviously all the bug fixes.
RELEASE_2_8_0 would contain ... 2.8.0, what a surprise!
HEAD
branch 2_8
branch 2_8_0 // * 2006-01-23 *
release 2_8_0_0 // RC1 release 2_8_0_1 // RC2 release 2_8_0_2 // FINAL release 2_8_0_3 // very quick release (security fix, pl1)
I find this confusing. Are we talking only about CVS tags or also about the naming of the downloadable files?
I prefer if users clearly see what they download: phpMyAdmin-2.8.0-rc1 phpMyAdmin-2.8.0 phpMyAdmin-2.8.0.1 (used to be 2.8.0-pl1)
So I don't like the idea of 2.8.0.2 being a final one. This said, I see that MailScanner (http://mailscanner.info) are releasing their version 4.49.7-1 as their stable version (maybe this is their patch level 1 for the stable 4.49.7) but I don't like it. Maybe it's just me?
Marc
branch 2_8_1 normal fix reales
release 2_8_1_0 // RC1 ?? release 2_8_1_1 // FINAL release 2_8_1_2 // very quick release (security fix, pl1)
...
branch 2_9 // * 2006-03-?? *
...
just like this one:
http://weblogs.mozillazine.org/roadmap/archives/2005_12.html
to keep it small, we have always only two branches open
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi
On Fri, 20 Jan 2006 08:15:12 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I think Sebastian's idea is to say that release 2.8.1 does not have more features than 2.8.0, only bugfixes. Critical bugfixes can still be named with -plX.
Okay, this sounds reasonable for me. But maybe then we could abandon those -plX as it just complicates versioning scheme.
So it's time to clarify the branch names.
HEAD would contain the new features + obviously all the bug fixes.
RELEASE_2_8_0 would contain ... 2.8.0, what a surprise!
HEAD
branch 2_8
branch 2_8_0 // * 2006-01-23 *
release 2_8_0_0 // RC1 release 2_8_0_1 // RC2 release 2_8_0_2 // FINAL release 2_8_0_3 // very quick release (security fix, pl1)
I find this confusing. Are we talking only about CVS tags or also about the naming of the downloadable files?
i was mainly talking about the cvs tags/branches
I prefer if users clearly see what they download: phpMyAdmin-2.8.0-rc1 phpMyAdmin-2.8.0 phpMyAdmin-2.8.0.1 (used to be 2.8.0-pl1)
the downloads don't need the last version numbers
2.8.0.0 can named as 2.8-RC1 or 2.8.0 RC1 as download file name ... 2.8.0.3 can named as 2.8-pl1 if you _really_ want this plx 2.8.1.0 can named as 2.8.1 2.8.1.1 can named as 2.8.1-pl1
i also often saw
2.7.9 as 2.8-RC1 2.7.9.1 as 2.8-RC2 2.8 as 2.8(-Final)
normally the last (fourth) number is the build number,
So I don't like the idea of 2.8.0.2 being a final one. This said, I see that MailScanner (http://mailscanner.info) are releasing their version 4.49.7-1 as their stable version (maybe this is their patch level 1 for the stable 4.49.7) but I don't like it. Maybe it's just me?
the number after the - is the rpm paket version, not the app version
Sebastian Mendel schrieb:
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi
On Fri, 20 Jan 2006 08:15:12 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I think Sebastian's idea is to say that release 2.8.1 does not have more features than 2.8.0, only bugfixes. Critical bugfixes can still be named with -plX.
Okay, this sounds reasonable for me. But maybe then we could abandon those -plX as it just complicates versioning scheme.
So it's time to clarify the branch names.
HEAD would contain the new features + obviously all the bug fixes.
RELEASE_2_8_0 would contain ... 2.8.0, what a surprise!
HEAD
branch 2_8
branch 2_8_0 // * 2006-01-23 *
release 2_8_0_0 // RC1 release 2_8_0_1 // RC2 release 2_8_0_2 // FINAL release 2_8_0_3 // very quick release (security fix, pl1)
I find this confusing. Are we talking only about CVS tags or also about the naming of the downloadable files?
i was mainly talking about the cvs tags/branches
I prefer if users clearly see what they download: phpMyAdmin-2.8.0-rc1 phpMyAdmin-2.8.0 phpMyAdmin-2.8.0.1 (used to be 2.8.0-pl1)
the downloads don't need the last version numbers
2.8.0.0 can named as 2.8-RC1 or 2.8.0 RC1 as download file name ... 2.8.0.3 can named as 2.8-pl1 if you _really_ want this plx 2.8.1.0 can named as 2.8.1 2.8.1.1 can named as 2.8.1-pl1
i also often saw
2.7.9 as 2.8-RC1 2.7.9.1 as 2.8-RC2 2.8 as 2.8(-Final)
normally the last (fourth) number is the build number,
http://en.wikipedia.org/wiki/Version
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi
On Fri, 20 Jan 2006 08:15:12 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
I think Sebastian's idea is to say that release 2.8.1 does not have more features than 2.8.0, only bugfixes. Critical bugfixes can still be named with -plX.
Okay, this sounds reasonable for me. But maybe then we could abandon those -plX as it just complicates versioning scheme.
So it's time to clarify the branch names.
HEAD would contain the new features + obviously all the bug fixes.
RELEASE_2_8_0 would contain ... 2.8.0, what a surprise!
HEAD
branch 2_8
branch 2_8_0 // * 2006-01-23 *
release 2_8_0_0 // RC1 release 2_8_0_1 // RC2 release 2_8_0_2 // FINAL release 2_8_0_3 // very quick release (security fix, pl1)
I find this confusing. Are we talking only about CVS tags or also about the naming of the downloadable files?
i was mainly talking about the cvs tags/branches
Ok, then I agree with your suggestion.
I prefer if users clearly see what they download: phpMyAdmin-2.8.0-rc1 phpMyAdmin-2.8.0 phpMyAdmin-2.8.0.1 (used to be 2.8.0-pl1)
the downloads don't need the last version numbers
2.8.0.0 can named as 2.8-RC1 or 2.8.0 RC1 as download file name ... 2.8.0.3 can named as 2.8-pl1 if you _really_ want this plx
No, I don't really want to have the -plX suffix, but we will have to be careful if the tags and release names do not match.
Michal suggested that a quick fix to 2.8.0 be named 2.8.0.1, I agree. But the version having a 2.8.0.1 in the filename would have a 2_8_0_3 tag, because of the potential of two RCs and one final?
2.8.1.0 can named as 2.8.1 2.8.1.1 can named as 2.8.1-pl1
i also often saw
2.7.9 as 2.8-RC1 2.7.9.1 as 2.8-RC2 2.8 as 2.8(-Final)
normally the last (fourth) number is the build number,
So I don't like the idea of 2.8.0.2 being a final one. This said, I see that MailScanner (http://mailscanner.info) are releasing their version 4.49.7-1 as their stable version (maybe this is their patch level 1 for the stable 4.49.7) but I don't like it. Maybe it's just me?
the number after the - is the rpm paket version, not the app version
On Tue, 24 Jan 2006 16:05:08 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
2.8.0.0 can named as 2.8-RC1 or 2.8.0 RC1 as download file name ... 2.8.0.3 can named as 2.8-pl1 if you _really_ want this plx 2.8.1.0 can named as 2.8.1 2.8.1.1 can named as 2.8.1-pl1
I find this extremely confusing, .0 once means RC and second time it is final release. You should be able to easily find tag for release.
Michal Čihař schrieb:
On Tue, 24 Jan 2006 16:05:08 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
2.8.0.0 can named as 2.8-RC1 or 2.8.0 RC1 as download file name ... 2.8.0.3 can named as 2.8-pl1 if you _really_ want this plx 2.8.1.0 can named as 2.8.1 2.8.1.1 can named as 2.8.1-pl1
I find this extremely confusing, .0 once means RC and second time it is final release. You should be able to easily find tag for release.
yes, version numbering in CVS and version naming for released file packages is not the same/synchron
On Wed, 25 Jan 2006 10:13:21 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
Michal Čihař schrieb:
On Tue, 24 Jan 2006 16:05:08 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
2.8.0.0 can named as 2.8-RC1 or 2.8.0 RC1 as download file name ... 2.8.0.3 can named as 2.8-pl1 if you _really_ want this plx 2.8.1.0 can named as 2.8.1 2.8.1.1 can named as 2.8.1-pl1
I find this extremely confusing, .0 once means RC and second time it is final release. You should be able to easily find tag for release.
yes, version numbering in CVS and version naming for released file packages is not the same/synchron
But it should be, otherwise it is easy to make mistakes.
Marc Delisle schrieb:
Hi,
I suggest 2.7.1-rc1 (or beta) on Jan 29th. I don't think we can "deglobalize" for 2.7.1, but we should be aiming to test/stabilize the tree before any bigger change.
I would like to fix those bugs before:
- 1376314: in some cases, SHOW GRANTS does not return the db-specific
privileges
- 1396998: exact row count for VIEWs
Anything else you feel is urgent?
i have marked bugs to be fixed before 2.7.1 with higher priority
On Fri, 20 Jan 2006 13:34:26 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
Marc Delisle schrieb:
Hi,
I suggest 2.7.1-rc1 (or beta) on Jan 29th. I don't think we can "deglobalize" for 2.7.1, but we should be aiming to test/stabilize the tree before any bigger change.
I would like to fix those bugs before:
- 1376314: in some cases, SHOW GRANTS does not return the db-specific
privileges
- 1396998: exact row count for VIEWs
Anything else you feel is urgent?
i have marked bugs to be fixed before 2.7.1 with higher priority
I also added one...
-
Marc Delisle -
Michal Čihař -
Sebastian Mendel