I have an SMTP message sending routine which allows sending simple e-mails, which I'd like to build as my first mod for a learning project. Anyone willing to hold my hand as I run into problems?
Amgine
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To prevent any mix-up in meaning between CVS modules and PHPWebSite modules, a CVS module shall be referred to as 'module' and a PHPWebSite Module shall be referred to as 'plugin'.
2. Modules
Within the Repository I suggest we split the repository into 2 modules:
* Documentation
* Modules
Within the documentation module we can keep documentation on:
* Writing a plugin from scratch
* Upgrading a module to work with 0.8.0 and above
* Coding Standards
* CVS Usage
Within the 'Modules' module we keep the source files for all the plugins that we host, each in its own directory.
-------------------------------------------------------------------------------
3. CVS Branching and Tagging
When talking about tagging, I am referring to named, symbolic tags of files. I don't forsee any need to branch or tag revisions within the 'documentation' module, so any suggestions made here are for the 'Modules' module only.
3.1 Tagging Modules as working with Versions of PHPWS
For ease of administration, whenever a plugin has been successfully installed and tested with a specific numbered release of PHPWebSite, it should be tagged in the repository as such. e.g. If a version of a plugin has been tested to work with PHPWebSite 0.8, it should be tagged as 'works-with-0_8' I forsee this hapenning only for major and minor version updates of PHPWS, e.g. X.X, and not for incremental updates, e.g. X.X.X
3.2 Marking Releases / Branching of plugin versions
3.2.1 Marking Releases
Whenever you wish to make a new release of a plugin you should mark the files for that version as being a new release. e.g. If you have a project that has just reached its stable release, you should cd to your plugin directory and perform a command similar to: cvs tag release-1_0_0 . where '1.0.0' is the release number. This marks all files in the directoryas being for that release. You may also tag individual files.
3.2.2 Branching
Let's say you have released 3 versions of your plugin, 1.0.0 , 1.0.1 and 1.1.0 and are currently working on version 1.1.1. By default a checkout of your plugin directory will give you the latest version of the files, namely the working files for release 1.1.1. Say someone has found a bug in version 1.0.1 of your plugin and you need to make a bugfix to it. You would need to checkout the files for release 1.0.1 and alter them. This is how you do this. In these examples, we assume that your plugin is in the plugins directory and is an English release.
If you haven't already checked out the latest working copies of your files, do so: cvs checkout modules/plugins/english/your-plugin
Cd into the working copy directory: cd modules/plugins/english/your-plugin
You now need to branch all files from the release-1_0_1 release which has the bug in it: cvs rtag -b -r release-1_0_1 release-1_0_1-bugfixes modules/plugins/english/your-plugin The '-b' tells CVS to branch. the '-r' tells CVS which version to branch from ('release-1_0_1'). 'release-1_0_1-bugfixes' is the name of the branch and 'modules/your-plugin' is the path to your plugin within the CVS structure. Now we have created the branch, we need a copy of it.
First of all, cd out of the working copy: cd ../../../..
Now check out the newly branched copy of your plugin to a new directory: mkdir release101 cd release101 cvs checkout -r release-1_0_1-bugfixes modules/plugins/english/your-plugin Where 'release-1_0_1-bugfixes' is the branch we just created and 'your-plugin' is the name of your plugin.
You can now enter that directory, edit the files and commit them back to that branch: cd modules/plugins/english/your-plugin [edit your files] cvs com -m "Fixed some bugs"
If, however, the bug also affects release-1_1_0, you will need to merge the bugfix into that version too. To do this, you need to check out that version (release-1_1_0).
First cd out of any other copies of the plugin you are in: cd ../../../../..
Now issue the commands: mkdir release110 cd release110 cvs checkout -r release-1_1_0 modules/plugins/english/your-plugin Where 'your-plugin' is the name of your plugin.
Now merge the fixed files (from the release-1_0_1-bugfixes branch) back into the release-1_1_0 branch with the following command: cvs checkout -j release-1_0_1-bugfixes modules/plugins/english/your-plugin
If there are any conflicts you will need to resolve them by hand.
You can then commit the merged changes into 'release-1_1_0' -------------------------------------------------------------------------------
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using the great module documentation to write this thing... but I have a question:
in the install script example, $title & $content are defined as globals. Somewhat recent discussion I vaguely remember had the globals no longer being required? Could these variable be passed to the function (e.g. function setup($title, $content))?
Amgine
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have an SMTP message sending routine which allows sending simple e-mails, which I'd like to build as my first mod for a learning project. Anyone willing to hold my hand as I run into problems?
Amgine
// added hard returns arbitrarily for readability
PHPWebSite Plugin Forge - CVS Repository Structure Philip McAllister September 8, 2001 Revision: $Id: cvs-info.txt,v 1.3 2001/10/24 23:18:56 icerunner Exp $
-------------------------------------------------------------------------------
1. Introduction
1.1 Naming Convention
To prevent any mix-up in meaning between CVS modules and PHPWebSite modules, a CVS module shall be referred to as 'module' and a PHPWebSite Module shall be referred to as 'plugin'.
1.2 Prerequisites Knowledge of CVS including committing, updating, tagging and branching. For a good tutorial on CVS, try this URL: http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/cvs/
-------------------------------------------------------------------------------
2. Modules
Within the Repository I suggest we split the repository into 2 modules:
* Documentation
* Modules
Within the documentation module we can keep documentation on:
* Writing a plugin from scratch
* Upgrading a module to work with 0.8.0 and above
* Coding Standards
* CVS Usage
Within the 'Modules' module we keep the source files for all the plugins that we host, each in its own directory.
-------------------------------------------------------------------------------
3. CVS Branching and Tagging
When talking about tagging, I am referring to named, symbolic tags of files. I don't forsee any need to branch or tag revisions within the 'documentation' module, so any suggestions made here are for the 'Modules' module only.
3.1 Tagging Modules as working with Versions of PHPWS
For ease of administration, whenever a plugin has been successfully installed and tested with a specific numbered release of PHPWebSite, it should be tagged in the repository as such. e.g. If a version of a plugin has been tested to work with PHPWebSite 0.8, it should be tagged as 'works-with-0_8' I forsee this hapenning only for major and minor version updates of PHPWS, e.g. X.X, and not for incremental updates, e.g. X.X.X
3.2 Marking Releases / Branching of plugin versions
3.2.1 Marking Releases
Whenever you wish to make a new release of a plugin you should mark the files for that version as being a new release. e.g. If you have a project that has just reached its stable release, you should cd to your plugin directory and perform a command similar to: cvs tag release-1_0_0 . where '1.0.0' is the release number. This marks all files in the directoryas being for that release. You may also tag individual files.
3.2.2 Branching
Let's say you have released 3 versions of your plugin, 1.0.0 , 1.0.1 and 1.1.0 and are currently working on version 1.1.1. By default a checkout of your plugin directory will give you the latest version of the files, namely the working files for release 1.1.1. Say someone has found a bug in version 1.0.1 of your plugin and you need to make a bugfix to it. You would need to checkout the files for release 1.0.1 and alter them. This is how you do this. In these examples, we assume that your plugin is in the plugins directory and is an English release.
If you haven't already checked out the latest working copies of your files, do so: cvs checkout modules/plugins/english/your-plugin
Cd into the working copy directory: cd modules/plugins/english/your-plugin
You now need to branch all files from the release-1_0_1 release which has the bug in it: cvs rtag -b -r release-1_0_1 release-1_0_1-bugfixes modules/plugins/english/your-plugin The '-b' tells CVS to branch. the '-r' tells CVS which version to branch from ('release-1_0_1'). 'release-1_0_1-bugfixes' is the name of the branch and 'modules/your-plugin' is the path to your plugin within the CVS structure. Now we have created the branch, we need a copy of it.
First of all, cd out of the working copy: cd ../../../..
Now check out the newly branched copy of your plugin to a new directory: mkdir release101 cd release101 cvs checkout -r release-1_0_1-bugfixes modules/plugins/english/your-plugin Where 'release-1_0_1-bugfixes' is the branch we just created and 'your-plugin' is the name of your plugin.
You can now enter that directory, edit the files and commit them back to that branch: cd modules/plugins/english/your-plugin [edit your files] cvs com -m "Fixed some bugs"
If, however, the bug also affects release-1_1_0, you will need to merge the bugfix into that version too. To do this, you need to check out that version (release-1_1_0).
First cd out of any other copies of the plugin you are in: cd ../../../../..
Now issue the commands: mkdir release110 cd release110 cvs checkout -r release-1_1_0 modules/plugins/english/your-plugin Where 'your-plugin' is the name of your plugin.
Now merge the fixed files (from the release-1_0_1-bugfixes branch) back into the release-1_1_0 branch with the following command: cvs checkout -j release-1_0_1-bugfixes modules/plugins/english/your-plugin
If there are any conflicts you will need to resolve them by hand.
You can then commit the merged changes into 'release-1_1_0' -------------------------------------------------------------------------------
Using the great module documentation to write this thing... but I have a question:
in the install script example, $title & $content are defined as globals. Somewhat recent discussion I vaguely remember had the globals no longer being required? Could these variable be passed to the function (e.g. function setup($title, $content))?
Amgine