[Phpmyadmin-devel] changelog strcutre
Hi, how about changing our changelog structure? are you all happy with current structure? some suggestion: - date only once per day - prefix type if change: bugfix, change, new - add module info, f.e. sqlparser, config, themes, import, ... release info in trunk changelog do says nothing - if we not also include info in later chnages if it was backported to any other branch do we really need to list all changed files? i think this comes from long ago when no versioning system was used!? f.e.: 2006-07-13 User - USer - BUGFIX: #123456 - bug report title - BUGFIX: some notices User2 - USer2 + NEW: [themes] new feature in themes / CHANGED: [gui] changed all layout table into fieldsets 2006-07-12 User - User * SECURITY: #123458 - blah blah [QA_2_10, QA_2_9] 2006-07-11 User - User > BRANCH: create branch QA_2_10 -- Sebastian Mendel www.sebastianmendel.de
Sebastian Mendel a écrit :
Hi,
how about changing our changelog structure?
are you all happy with current structure?
I agree with your proposed changes. It's important also to credit people for patches, translations, etc. in the ChangeLog (and in Documentation.html for big credits). Why the "create branch" messages?
some suggestion:
- date only once per day - prefix type if change: bugfix, change, new - add module info, f.e. sqlparser, config, themes, import, ...
release info in trunk changelog do says nothing - if we not also include info in later chnages if it was backported to any other branch
do we really need to list all changed files? i think this comes from long ago when no versioning system was used!?
f.e.:
2006-07-13 User - USer - BUGFIX: #123456 - bug report title - BUGFIX: some notices User2 - USer2 + NEW: [themes] new feature in themes / CHANGED: [gui] changed all layout table into fieldsets
2006-07-12 User - User * SECURITY: #123458 - blah blah [QA_2_10, QA_2_9]
2006-07-11 User - User > BRANCH: create branch QA_2_10
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Hi,
how about changing our changelog structure?
are you all happy with current structure?
I agree with your proposed changes. It's important also to credit people for patches, translations, etc. in the ChangeLog (and in Documentation.html for big credits).
yes - of course, like we do it now, or? just an appendix 'thanks to loveleyUser' in case of patches or other merged code
Why the "create branch" messages?
to see that all changes before this message are in this branch too
some suggestion:
- date only once per day - prefix type if change: bugfix, change, new - add module info, f.e. sqlparser, config, themes, import, ...
release info in trunk changelog do says nothing - if we not also include info in later chnages if it was backported to any other branch
do we really need to list all changed files? i think this comes from long ago when no versioning system was used!?
f.e.:
2006-07-13 User - USer - BUGFIX: #123456 - bug report title - BUGFIX: some notices User2 - USer2 + NEW: [themes] new feature in themes / CHANGED: [gui] changed all layout table into fieldsets
2006-07-12 User - User * SECURITY: #123458 - blah blah [QA_2_10, QA_2_9]
2006-07-11 User - User > BRANCH: created branch QA_2_10
-- Sebastian Mendel www.sebastianmendel.de
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Hi,
how about changing our changelog structure?
are you all happy with current structure? I agree with your proposed changes. It's important also to credit people for patches, translations, etc. in the ChangeLog (and in Documentation.html for big credits).
yes - of course, like we do it now, or?
All entries for 2007 could be changed to the new format. I suggest that every committer changes his part (unless you are volunteer :) ).
just an appendix 'thanks to loveleyUser' in case of patches or other merged code
Why the "create branch" messages?
to see that all changes before this message are in this branch too
Hmmm, changes later than this "create branch" message can also be in this branch because we often backport.
some suggestion:
- date only once per day - prefix type if change: bugfix, change, new - add module info, f.e. sqlparser, config, themes, import, ...
release info in trunk changelog do says nothing - if we not also include info in later chnages if it was backported to any other branch
do we really need to list all changed files? i think this comes from long ago when no versioning system was used!?
f.e.:
2006-07-13 User - USer - BUGFIX: #123456 - bug report title - BUGFIX: some notices User2 - USer2 + NEW: [themes] new feature in themes / CHANGED: [gui] changed all layout table into fieldsets
2006-07-12 User - User * SECURITY: #123458 - blah blah [QA_2_10, QA_2_9]
2006-07-11 User - User > BRANCH: created branch QA_2_10
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Hi,
how about changing our changelog structure?
are you all happy with current structure? I agree with your proposed changes. It's important also to credit people for patches, translations, etc. in the ChangeLog (and in Documentation.html for big credits). yes - of course, like we do it now, or?
All entries for 2007 could be changed to the new format. I suggest that every committer changes his part (unless you are volunteer :) ).
i could do - but i would wait for other comments
just an appendix 'thanks to loveleyUser' in case of patches or other merged code
Why the "create branch" messages? to see that all changes before this message are in this branch too
Hmmm, changes later than this "create branch" message can also be in this branch because we often backport.
yes, thats why i wrote we should mark such backports 2006-07-12 User - User * SECURITY: #123458 - blah blah [QA_2_10, QA_2_9]
some suggestion:
- date only once per day - prefix type if change: bugfix, change, new - add module info, f.e. sqlparser, config, themes, import, ...
release info in trunk changelog do says nothing - if we not also include info in later chnages if it was backported to any other branch
do we really need to list all changed files? i think this comes from long ago when no versioning system was used!?
f.e.:
2006-07-13 User - USer - BUGFIX: #123456 - bug report title - BUGFIX: some notices User2 - USer2 + NEW: [themes] new feature in themes / CHANGED: [gui] changed all layout table into fieldsets
2006-07-12 User - User * SECURITY: #123458 - blah blah [QA_2_10, QA_2_9]
2006-07-11 User - User > BRANCH: created branch QA_2_10
-- Sebastian Mendel www.sebastianmendel.de
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Hi,
how about changing our changelog structure?
are you all happy with current structure? I agree with your proposed changes. It's important also to credit people for patches, translations, etc. in the ChangeLog (and in Documentation.html for big credits). yes - of course, like we do it now, or? All entries for 2007 could be changed to the new format. I suggest that every committer changes his part (unless you are volunteer :) ).
i could do - but i would wait for other comments
Michal, any comment on this? Marc
just an appendix 'thanks to loveleyUser' in case of patches or other merged code
Why the "create branch" messages? to see that all changes before this message are in this branch too Hmmm, changes later than this "create branch" message can also be in this branch because we often backport.
yes, thats why i wrote we should mark such backports
2006-07-12 User - User * SECURITY: #123458 - blah blah [QA_2_10, QA_2_9]
some suggestion:
- date only once per day - prefix type if change: bugfix, change, new - add module info, f.e. sqlparser, config, themes, import, ...
release info in trunk changelog do says nothing - if we not also include info in later chnages if it was backported to any other branch
do we really need to list all changed files? i think this comes from long ago when no versioning system was used!?
f.e.:
2006-07-13 User - USer - BUGFIX: #123456 - bug report title - BUGFIX: some notices User2 - USer2 + NEW: [themes] new feature in themes / CHANGED: [gui] changed all layout table into fieldsets
2006-07-12 User - User * SECURITY: #123458 - blah blah [QA_2_10, QA_2_9]
2006-07-11 User - User > BRANCH: created branch QA_2_10
Hi sorry for not commenting so long, I delayed it for later, when I will have more time and then I forgot :-). On Tue, 13 Feb 2007 12:29:56 +0100 Sebastian Mendel <lists@sebastianmendel.de> wrote:
how about changing our changelog structure?
are you all happy with current structure?
some suggestion:
- date only once per day
Why to include date at all? I thing only thing which is really interesting to changelog reader is version information. Details are always available in subversion.
- prefix type if change: bugfix, change, new
There is always question what is change and what is new...
- add module info, f.e. sqlparser, config, themes, import, ...
Ok for me.
2006-07-13 User - USer
Why is here name twice?
- BUGFIX: #123456 - bug report title - BUGFIX: some notices
repeating BUGFIX on each line looks a bit overhead for me. How about only sign which will determine type of record? 1.2.3 - bug #123465 [themes] - fixed something (User Name <user@nowhere.org>) + RFE #654321 [gui] - added support for blah and make it look better (Another User <user@somewhere.org>) BTW: When at this: try to commit to subversion with same message as you write in changelog. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Michal Čihař a écrit :
Hi
sorry for not commenting so long, I delayed it for later, when I will have more time and then I forgot :-).
On Tue, 13 Feb 2007 12:29:56 +0100 Sebastian Mendel <lists@sebastianmendel.de> wrote:
how about changing our changelog structure?
are you all happy with current structure?
some suggestion:
- date only once per day
Why to include date at all? I thing only thing which is really interesting to changelog reader is version information. Details are always available in subversion.
I would prefer to keep the date because it's easier to read directly in the ChangeLog, instead of doing research in svn.
- prefix type if change: bugfix, change, new
There is always question what is change and what is new...
Yeah I was thinking the same. A new feature would be "new", a change would be a change of behavior like what happens with the top navi icon?
- add module info, f.e. sqlparser, config, themes, import, ...
Ok for me.
Ok for me too, but we have to be careful, trying to use the same terms consistently.
2006-07-13 User - USer
Why is here name twice?
Maybe Sebastian meant: Marc Delisle - lem9
- BUGFIX: #123456 - bug report title - BUGFIX: some notices
repeating BUGFIX on each line looks a bit overhead for me. How about only sign which will determine type of record?
1.2.3
- bug #123465 [themes] - fixed something (User Name <user@nowhere.org>) + RFE #654321 [gui] - added support for blah and make it look better (Another User <user@somewhere.org>)
I'm not sure I like the syntax - BUGFIX + NEW / CHANGE Is there some convention somewhere about these symbols? Is this based on diff's output? I would prefer * BUGFIX * NEW * CHANGE
BTW: When at this: try to commit to subversion with same message as you write in changelog.
Good point. Here, cut&paste is useful! Why, oh why can't we generate the ChangeLog from subversion's info?
------------------------------------------------------------------------
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
------------------------------------------------------------------------
_______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Mon, 19 Feb 2007 10:36:57 -0500 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
Good point. Here, cut&paste is useful! Why, oh why can't we generate the ChangeLog from subversion's info?
We definitely could :-). That's where I want to go - details are in subversion and summary is in changelog. When user comes and want to see what's new in this version, he can read changelog and see this quickly. This is impossible with current changelog. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Michal Čihař a écrit :
On Mon, 19 Feb 2007 10:36:57 -0500 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
Good point. Here, cut&paste is useful! Why, oh why can't we generate the ChangeLog from subversion's info?
We definitely could :-). That's where I want to go - details are in subversion and summary is in changelog. When user comes and want to see what's new in this version, he can read changelog and see this quickly. This is impossible with current changelog.
Can subversion automatically generate a ChangeLog? Marc
On Mon, 19 Feb 2007 11:02:35 -0500 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
Michal Čihař a écrit :
On Mon, 19 Feb 2007 10:36:57 -0500 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
Good point. Here, cut&paste is useful! Why, oh why can't we generate the ChangeLog from subversion's info?
We definitely could :-). That's where I want to go - details are in subversion and summary is in changelog. When user comes and want to see what's new in this version, he can read changelog and see this quickly. This is impossible with current changelog.
Can subversion automatically generate a ChangeLog?
You can easily convert svn log to something what looks like ChangeLog, there are also some tools which do this, eg. svn2log[1], however I'm not sure whether it is possible to do this at commit time. [1] http://www.core.com.pl/svn2log/ -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Michal Čihař a écrit :
On Mon, 19 Feb 2007 11:02:35 -0500 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
Michal Čihař a écrit :
On Mon, 19 Feb 2007 10:36:57 -0500 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
Good point. Here, cut&paste is useful! Why, oh why can't we generate the ChangeLog from subversion's info? We definitely could :-). That's where I want to go - details are in subversion and summary is in changelog. When user comes and want to see what's new in this version, he can read changelog and see this quickly. This is impossible with current changelog. Can subversion automatically generate a ChangeLog?
You can easily convert svn log to something what looks like ChangeLog, there are also some tools which do this, eg. svn2log[1], however I'm not sure whether it is possible to do this at commit time.
Well, this tool generates "gnu-style changelogs" which include the filenames :) Ok, auto-generating is not a priority; also I like the fact that in the same revision, the changelog is updated because some users are looking at the latest changelog to see what happens. Marc
On Mon, 19 Feb 2007 11:55:24 -0500 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
Michal Čihař a écrit :
You can easily convert svn log to something what looks like ChangeLog, there are also some tools which do this, eg. svn2log[1], however I'm not sure whether it is possible to do this at commit time.
Well, this tool generates "gnu-style changelogs" which include the filenames :)
But it has --no-files option :-) -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Michal Čihař a écrit :
On Mon, 19 Feb 2007 11:55:24 -0500 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
Michal Čihař a écrit :
You can easily convert svn log to something what looks like ChangeLog, there are also some tools which do this, eg. svn2log[1], however I'm not sure whether it is possible to do this at commit time.
[1] http://www.core.com.pl/svn2log/ Well, this tool generates "gnu-style changelogs" which include the filenames :)
But it has --no-files option :-)
Ok I have not even tried it :) Anyway, I think we still want a changelog updated at the same time as the commit. I checked the hook scripts https://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1#script... but there is nothing about changelog generation. So .. what do we do for the new changelog format? only discuss or do something? :) Marc
Michal Čihař schrieb:
On Tue, 13 Feb 2007 12:29:56 +0100 Sebastian Mendel <lists@sebastianmendel.de> wrote:
how about changing our changelog structure?
are you all happy with current structure?
some suggestion:
- date only once per day
Why to include date at all? I thing only thing which is really interesting to changelog reader is version information. Details are always available in subversion.
so use CHANGELOG only as 'End-User-Changelog'? so something like: 2007-02-09 Michal Čihař <michal@cihar.com> * lang/czech: Fix syntax error (sorry for that). will not appear there ... ? in this case cause it was introduced and fixed between releases
2006-07-13 User - USer
Why is here name twice?
Sebastian Mendel - cybot_tm
- BUGFIX: #123456 - bug report title - BUGFIX: some notices
repeating BUGFIX on each line looks a bit overhead for me. How about only sign which will determine type of record?
onyl sign would be fine for me - but for the end-user?
1.2.3
- bug #123465 [themes] - fixed something (User Name <user@nowhere.org>) + RFE #654321 [gui] - added support for blah and make it look better (Another User <user@somewhere.org>)
in brackets the user who commited? if we have a detailed changelog (generated by subversion) there is no need for names, too 2.11-dev ====================== - bug #1616486 [dblist] server_databases does not show all databases - [sqp] updated MySQL function and column names, reserved and forbidden words - bug #1657045 [sqp] Spatial functions not supported - bug #1657037 [sqp] Missing column type "geometry" + [lang] spanish update, thanks to Daniel Hinostroza . [general] get rid of $propicon + [config] new $cfg['LeftLogoLinkWindow'] to decide in which window the logo-linked page will appear + = new - = bugfixc . = internal change (not really interesting for end user) -- Sebastian Mendel www.sebastianmendel.de
On Thu, 22 Feb 2007 14:32:40 +0100 Sebastian Mendel <lists@sebastianmendel.de> wrote:
so use CHANGELOG only as 'End-User-Changelog'?
Yes.
so something like:
2007-02-09 Michal Čihař <michal@cihar.com> * lang/czech: Fix syntax error (sorry for that).
will not appear there ... ?
in this case cause it was introduced and fixed between releases
Exactly.
2.11-dev ======================
- bug #1616486 [dblist] server_databases does not show all databases - [sqp] updated MySQL function and column names, reserved and forbidden words - bug #1657045 [sqp] Spatial functions not supported - bug #1657037 [sqp] Missing column type "geometry" + [lang] spanish update, thanks to Daniel Hinostroza . [general] get rid of $propicon + [config] new $cfg['LeftLogoLinkWindow'] to decide in which window the logo-linked page will appear
+ = new - = bugfixc . = internal change (not really interesting for end user)
Looks okay to me. BTW: This is format I use for another project, we're now quite close ;-). The names which are mentioned are external contributors. [!] Important [+] New functionality [*] Changes in existing functionality [-] Fixed error 2007???? - 1.09.20 [-] * Added include paths to MSVC configuration files. [+] * Support for sending file to phone (--sendfile). [-] * Russian translation update (Acid Jack). [-] * Fixed possible uninitalized value in date decoding (Stanislav Brabec). -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Sebastian Mendel a écrit :
2.11-dev ======================
- bug #1616486 [dblist] server_databases does not show all databases - [sqp] updated MySQL function and column names, reserved and forbidden words - bug #1657045 [sqp] Spatial functions not supported - bug #1657037 [sqp] Missing column type "geometry" + [lang] spanish update, thanks to Daniel Hinostroza . [general] get rid of $propicon + [config] new $cfg['LeftLogoLinkWindow'] to decide in which window the logo-linked page will appear
+ = new - = bugfixc . = internal change (not really interesting for end user)
Ok for me too. Marc
participants (3)
-
Marc Delisle -
Michal Čihař -
Sebastian Mendel